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.

vWorkspace Web Access is one of the most popular ways for our customers to provide access to their applications in a seamless, simple way. Out of the box, vWorkspace Web Access has quite a couple of options to allow customers to customize the vWorkspace Web Access pages to fit their personal needs. Still, some customers want to customize vWorkspace Web Access even further. Since vWorkspace Web Access is built on web-industry standards like ASP.net and ASP.net features such as “Themes” and “Skins”, it is relatively easy to take vWorkspace Web Access customization even further. To make it easier for our customers to do so, we have included a document called ”vWorkspaceWebAccess6.2_CustomizationGuide.pdf” in every download of vWorkspace 6.2. It is located in the documents folder. Here’s an example of a customized Quesr vWorkspace Web Access instance:

While on the subject of customization, remember that Quest vWorkspace 6.2 also included experimental integration with Microsoft Sharepoint. The associated documentation for this Microsoft Sharepoint integration can be found in the download section of vWorkspace.com under the documentation header.

Happy customizing! ( or maybe I should have called it pimping…? )

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!

Initialization deploys (if it doesn’t exist) and starts the Quest Data Collector Service (pndcsvc.exe).  This also writes the farm and computer group identity into the computer’s registry.  Initialization happens automatically when a computer is created or imported into the vWorkspace Management Console.  The Computer Administrative Account defined on the properties of the computer group is the account responsible for the installation.  The main responsibilities of the Quest Data Collector Service are:

1. To send heartbeats to the broker (every 5 minutes, by default) to say I’m alive and able to accept connections.
2. To collect information via WMI like IP Address, hostname, OS (all of the 20 or so columns listed in the vWorkspace Management Console).
3. To manage the Remote Desktop Users, Administrators and Power Users groups’ membership. 

If one removes a computer from a group in pnconsole, the broker instructs the datacollector service to remove the farm and computer group identity from the registry so it can join a different group.  The computer in question must be on for this to work.

Quest Tools for the Managed Desktop, otherwise known as pntools is installed to provide the following features:

1. Credentials Passthru
2. Universal Printer Driver
3. Seamless Windows Engine
4. USB Virtual Hub
5. Multimonitor Support
6. Local Text Echo
7. Graphics Acceleration
8. Bi-directional audio

Since installing pntools replaces the Microsoft GINA with pngina.dll, and because there are 32 and 64 bit desktop OS, we choose to not automatically deploy pntools at computer initialization.  Pntools can however be deployed as part of the computer template, via automated task or by right clicking on a single desktop, multiple desktops or an entire group of desktops and choosing to install pntools.

Pntools is only available for Managed Desktops, i.e. VDI.  For Terminal Services / Remote Desktop Services, one must run the full vWorkspace installer on the server and install vWorkspace Enterprise Edition to ge the equivalent functionality.

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?

For anyone that’s ever worked on a helpdesk, as a desktop administrator or Terminal Services/Citrix administrator it’s no news that user profile management is, and has been an issue since forever. 

Let’s define the problems with Windows User Profiles:

1.  Profile Corruption - Users logon and their profile does not load, leaving them with a temporary profile without any of their personalizations

2.  Logon speed (or lack thereof) - as profiles age the ntuser.dat file grows and the number of files associated with the user’s profile increases.  These cause the user’s logon time to increase over time, starting at 10-15 seconds when the profile is new, and increasing to minutes as time goes on.

3.  It’s not generally accepted to use the same profile for diffent OS, i.e. XP and Server 2003.  In an environment with Terminal Services this typically leads administrators to using two completely different user profiles, for example one for the client OS and one for Windows Terminal Services.

4.  Support for application silos - In a Terminal Services or VDI environment users may access multiple hosts to get their applications, often without their knowledge.  Administrators have the option of using local profiles for each system, or risking use of roaming profiles getting bloated and corrupted due to the registry, start menu and app data being populated with items that have nothing to do with the system being used.

5.  Local user profile cleanup (or lack thereof) -  These profiles can consume massive amounts of disk space on shared systems, so administrators usually have to account for this space, or write scripts to delete them.

Via acquisition of Provision Networks in 2007, Quest acquired one of the only commercially available User Profile Management solutions.  The problem was that it only supported Windows Terminal Services.

In January of 2009 Quest released vWorkspace 6.0, the successor to Provision Networks Virtual Access Suite.  in vWorkspace 6.0 User Profile Management (also known as Metaprofiles) now fully supports Terminal Services, Virtual Desktops and Physical PCs.

So how does it work?

User Profile Management in vWorkspace is a client-server application, where there is an agent on the Virtual PC/Physical PC/Terminal Server, and one or more storage servers for maintaining the user settings. 

Everything is managed from the vWorkspace Management Console, and the components are:

Quest Metaprofiles Agent - Installed on virtual and/or physical desktops running Windows XP/Vista, or Terminal Servers running 2000/2003/2008.  Responsible for downloading compressed user settings (xml files) from the storage server, applying the settings at logon, exporting the settings deleting the local profile at logoff.

Quest Metaprofiles Storage Service - Installed on a Windows server OS hosting the storage service.  This is typically a dedicated virtual machine but could also be on a physical server.  Since this is a client-server application, there is no Windows File Share associated with the storage service.

Quest Connection Broker Service - responsible for directing the Metaprofiles Agent to the correct Storage Server.

A typical deployment of Quest User Profile Management consists of:

1.  Customized local Default User Profile, containing the minimum base user settings for all users logging on.  Common tweaks include removing desktop icons, favorites and eliminating the “Customizing your user preferences” dialog that appears logon for the first time.

2.  Use Group Policy to redirect My Documents, Desktop, Application Data and Start Menu to network file shares, so theses are not copied back and forth at logon/logoff and so roaming profiles are not configured.

3.  Define the application settings that users may customize, which users may customize the settings and on which desktop groups or terminal servers the settings will be applied.  These may be registry entries, directories or files.  Best practice would be to let GPO Folder Redirection manage the majority of files, and only use Quest User Profile Management for specific individual files or folders that are not handled by GPO.  Settings may be marked as “global”, meaning they will apply on any system, or “silo”, meaning they will only apply on specific desktop groups or terminal servers.

4.  Install the Microsoft User Profile Hive Cleanup service to ensure that user profiles are successfully unloaded at logoff.

What are the benefits of implementing Quest User Profile Management:

1.  Stable User Profiles - reduced administrative overhead and helpdesk calls

2.  Fast user logons - typically about 10 seconds, vs 30-60 seconds with roaming profiles

3.  Reduced storage requirements for profile data, since only compressed deltas are maintained, not the entire user profile

4.  Reduced number of Virtual PCs to maintain, as administrators can deploy non-persistent (temporarily assigned) desktops, where the user settings are dynamically applied at logon.

5.  No need to cleanup local user profiles or configure mandatory or roaming profiles.

6.  Quest User Profile Management is included in all versions of Quest vWorkspace, so it’s another critical feature that won’t require the purchase of another 3rd party user profile management tool.

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.

As you probably know Quest vWorkspace 6.0 supports a broad selection of leading hypervisors. Among the supported hypervisors is VMware ESX (more specifically VMware Virtual Infrastructure). To make it very easy for you to evaluate vWorkspace 6.0 in a VMware Virtual Infrastructure we have created a “getting started guide” which details all the steps you need to take to be able to start evaluating all the cool features in vWorkspace 6.0.

The guide will describe the requirements and the installation and configuration steps to get started with vWorkspace 6.0 in a VMware VI 3.x Environment. The following procedures are detailed:

• Downloading the Quest vWorkspace 6.0 Software
• Installing the Connection Broker
• Entering Customer Information
• Adding a VMware Virtual Infrastructure
• Creating Virtual Desktops from a template in the Managed Computer Group
• Installing PNTools
• Creating a Managed Application
• Using Evaluation Licenses
• Installing the Quest vWorkspace 6.0 Client
• Configuring AppPortal
• Launching AppPortal

Download the guide here: Getting Started Guide for Quest vWorkspace 6.0 in a VMware Virtual Infrastructure 3.x Environment.

If you are looking for a version of this guide that applies to version 5.10, please go here.

In our encounters with customers we learn a lot about what they want to achieve with Quest vWorkspace. Many customer use vWorkspace to be able to centralize and consolidate their application and desktop workloads, whether that is VDI, Terminal Services or other desktops. This centralization and consolidation of application and desktop workloads brings customers many advantages all of which (directly or indirectly) save the customer a lot of money. Let’s be honest, there’s no mystery there: all of us are being asked to do more with less (probably with even less in these challenging economic times) so Quest’s vWorkspace unique characteristics and realistic pricing makes it to be the solution of choice for even more customers today.

Of course there is no such thing as a free lunch. Any project to to centralize and consolidate application and desktop workloads is a comprehensive one. To be able to effectively judge or predict when this project will start to save your company money, a ROI (return on investment) calculation is often required. To be effective and realistic such a ROI investment needs to take in account many, many factors ranging from the “estimated cooling load factor” to the cost of a VECD license. I think that it is safe to say that creating a good ROI analysis is a tedious and time consuming task.

Well, not anymore! Quest has made available a free Quest vWorkspace ROI calculator that allows you to perform a ROI calculation tailored to your business. The Quest vWorkspace ROI calculator takes all the necessary factors and costs into account and even allows you to have full insight into the numbers used. If you want, you can change our default assumptions and use your own numbers. We even have an option to compare the cost of vWorkspace when using the different hypervisors supported by vWorkspace!

The Quest vWorkspace ROI calculator is free for anyone to use with registration only being required if you need to save a reports from the tool.

Go ahead, try out the Quest vWorkspace ROI calculator.