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!

Quest vWorkspace 6.x offers enhanced security to allow connections from only version 6.x of the Quest client. In some cases it is required to turn off this option, for example if you wanted to connect to the Farm from a Sunray terminal or a Wyse Thin OS based terminal. To enable compatibility mode you are required to add the following registry key on each server running the ‘Quest Connection Broker’ service:

HKLM\Software\Provision Networks\Common\Load And License Manager

CompatibilityMode = 1  REG_DWORD

Whilst we are looking at the compatibility mode it is also worth covering the setup for configuring Wyse Thin OS devices from the Quest vWorkspace server rather than using an FTP server.

Once you have configured your WNOS.INI and\or your RDP.INI files you need to store them on a broker server in “C:\Program Files\Quest\vWorkspace\WYSE\WNOS”, if you plan to use custom bitmaps for wallpapers, logon screen, icons etc. they would need to be stored in “C:\Program Files\Quest\vWorkspace\WYSE\WNOS\bitmap”. Once you have the INI files in place you can configure the terminals manually or use DHCP tags to automate this process. For the purposes of the example we will assume that the broker is using port 8080 and has an IP address of 192.168.1.1 (NB. You could also use the servers DNS name as long as it is resolvable).

If you want to configure the terminals using DHCP option tags you would need to create 161 and 188 (both with string values), 161 is the file server and 188 is the VDI broker. It is quite possible that in this environment that 161 and 188 are identical, however they are both still required. An example would be ‘http://192.168.1.1:8080’. If you wanted to configure the terminal manually you need to edit the Network Settings, click on the Servers tab and enter the File Server and VDI broker information in the relevant fields, again an example would be ‘http://192.168.1.1:8080’.

An example of the logon screen is below, I have enabled authentication and customized the logon screen in the WNOS.INI file:

An example of the Network Setup screen is below:

Currently the Wyse Thin OS supports published Desktops but not published Applications. Wyse also uses their own RDP client so the Quest RDP enhancements are not supported, however Wyse to offer their own set of RDP enhancements that could be used, these are referred to as TCX.

If you need some assistance creating the INI files there is a useful tool called ConfGen that will generate them, this can be found at: http://www.technicalhelp.de/

One of the core design goals of Quest vWorkspace is to provide customers with a flexible application and desktop delivery framework, regardless of the virtual infrastructure that they use. This requires us (we think) to provide advanced integration with all the leading virtual infrastructure products. To be honest, there are times that it is very evident to us that it would really be much easier to just support one (or two) virtual infrastructures (like many other vendors do), especially with new version of virtual infrastructures coming out all the time. Even though it requires significant development efforts to support  the leading virtual infrastructure products, we feel compelled to keep doing so and not choose the proverbial easy way out for us and for our customers so our customers can leverage their existing investments now and in the future.

This brings me to actual subject of this blog post: VMware vSphere. Ever since the early releases of VMware vSphere we have been working to make sure that Quest vWorkspace works with VMware vSphere to accommodate new and existing customers should they decide to use VMware vSphere as their virtualization infrastructure. It is therefore that I am happy to say that we officially support the following versions of Quest vWorkspace with VMware vSphere:

• Provision networks Virtual Access Suite 5.10 (build 161 )
• Quest vWorkspace 6.0 (HF3 )
• Quest vWorkspace 6.1

On another note, when researching vSphere I found out that VMware’s own VDI product (View) does not support vSphere yet. That really surprised me.
I guess this just emphasizes our position on providing good value for money for our customers.

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.

Remember that I mentioned the public Quest vWorkspace BETA program about a week ago? Yesterday we added two, publicly available, connections to this program. One is BETA 1 of Quest vWorkspace 6.2 and the other is BETA 1 of our Mac Client. We would very much love to hear what you think!

Participating in the BETA programs is as easy as signing in to our website with your existing account or, if you do not have an account, to register for one. Anyone can sign up for a account. A small note about our beta program: Quest Support does not support Beta and Release Candidate software via the normal support channels. Please email vWorkspace_beta@quest.com to provide feedback or obtain help with this pre-release software.

We look forward to welcoming you on our beta program soon!

One of the most popular features in Quest vWorkspace 6.1 is the tight integration with Microsoft System Center Virtual Machine Manager (SCVMM) 2008. The integration is very easy to configure but to make it even easier we have created a Quick Start guide to help you get started. As far as I know the Quick Start guide did not make it into the official 6.1 vWorkspace download, so to get the guide, either download it here or get it from the official Quest vWorkspace download site. The Quest vWorkspace 6.1 with Microsoft System Center Virtual Machine Manager Quick Start Guide, as well as many other documents, are listed under the documentation section.

If you are curious about some of the new technologies that we are working on at the Quest Desktop Virtualization Group, there is great news. Recently we launched a public beta program that allows anyone to participate. It’s very easy to take part in the program. Simply sign up on our website or use your existing account and access the downloads section. At the bottom there is a special section for beta software releases.We would love to hear your feedback!

Today the available beta programs are our new Multimonitor functionality (you could have virtual monitors within your RDP session!) and our new Linux vWorkspace client. More beta programs will become available as times passes. Look for the public beta of Quest vWorkspace 6.2 soon.

A small note about our beta program: Quest Support does not support Beta and Release Candidate software via the normal support channels. Please email vWorkspace_beta@quest.com to provide feedback or obtain help with this pre-release software.

We look forward to welcoming you on our beta program soon!