Geek Week VDI Day 5: Quest vWorkspace 7 summary

Day 5 of Geek Week: VDI actually corresponds with Day 5 of our testing week.

This post, like all five Geek Week: VDI wrap-up posts, was co-written by Brian & Gabe.

Day 5 of Geek Week: VDI actually corresponds with Day 5 of our testing week. Sluggish is a kind word for how we felt Friday morning after pulling four 16 hour days in a row, but it was pretty clear when Quest's Rob Mallicoat hit the door that he'd gotten a full night of sleep!

The Whiteboard

First, Rob explained the components of vWorkspace 7. In this test, we'll be using the vWorkspace connection broker with Hyper-V (although Quest also supports XenServer, ESX, and even Parallels). Since we're using Hyper-V, we'll also need to install SCVMM. Since Quest can also broker Remote Desktop or physical PC connections, he also takes a moment to explain how that works (it boils down to Quest treats desktops as single-user terminal servers, so it's just a logical extension). Finally, Rob explains what we should see when we take a look at Quest's EOP extensions to the RDP protocol.

Quest vWorkspace component installation

First up for our install was to copy over some blank VMs. The one we used for vWorkspace is 2008 R2 with IIS already installed. After that was copied over, we launched the vWorkspace setup and were presented with a screen asking for us to pick a Licensing Mode. This is the screen where you choose what edition of vWorkspace you're installing, and your choices here dictate what is pre-populated on the next screen. The choices here are "Hosted Desktops and Terminal Servers" (or Enterprise Edition), "Hosted Desktops Only" (or Desktop Services Edition), "Power Tools Suite for Terminal Servers" (or Standard Edition), or "Standalone Power Tools for Terminal Servers." Everything vWorkspace can do is in a single installer, and that's pretty cool. We chose Enterprise so that we had all the options.

After selecting the components we wanted (Web Interface, Managment Console), we chose to install a SQL Express database as opposed to using our existing SQL server. The only reason is that it's easier to use SQL Express since it's all configured automatically. Obviously, in production you'd use a regular SQL server.

Even though we're using Hyper-V, we haven't actually told vWorkspace that yet, so we're presented with a screen asking us to create a VMware Keystore File. If we were using VMware, we'd get a key from vCenter and enter it here, establishing a secure connection between vWorkspace and vCenter. Since we're not using VMware, we pass by that screen, as well as another similar screen for Virtual Iron users.

The last step in setup is what actually adds the server as a connection broker in the vWorkspace Management console. There has to be a reason that it isn't done automatically, so if you read this, Rob, and know the answer...let us know!

After a reboot, we jumped out to the vWorkspace website and pulled down some evaluation license files. This process involves copying the VMAC (a number resembling a MAC address that is generated based on what you enter on the Customer Information screen) from the connection broker server into an authorization system on the web. Once you do at, a license file is provided tailored specifically to that system.

Next, we had a bunch of configurations to make, including:

  • Pointing the vWorkspace server to SCVMM (where an agent resides in order to communicate with vWorkspace). If you don't have SCVMM, you would install the agent, or "Broker Helper," on every Hyper-V host.
  • Configuring time out settings for how long vWorkspace waits for SCVMM to respond for machine information, updates, and so on
  • Add a "virtualization entity," which is essentially adding a virutalization platform. In this case, we chose SCVMM, but there are also options for Virtuozzo, VMware datacenters, and more.

At this point, we can start working with desktops. This process involves:

  • Creating a desktop pool (or Computer Group).
  • Telling the desktop pool what entity it will run on, in this case SCVMM.
  • Assigning an administrative user for that desktop pool
  • VM assignments - Quest can assign users or devices to VM's based on different criteria (User, Device Name, Device Address, Organizational Unit, Group)
  • Access time tables
  • Automatic local group membership (can automatically assign each user to either the local Administrators or Power users group...or nothing more than the Remote Desktop Users group)
  • Connection settings like auto-log off, inactivity settings, and logoff action
  • Network settings like protocol (RDP or RGS), bandwidth optimization (which turns off Quest's bandwidth optimization if you have a third-party solution)
  • Bidirectional Audio
  • Pre-spun up VM's
  • Automated tasks for the desktop pool (telling VM's to sleep in off hours, for instance)

After going through the settings, we imported a template virtual machine that was already set up in SCVMM. As part of the process, we give the machine a base name that will have an automatically incremented number at the end. The actual creation of the VM can be schedule in the event you want to create many of them during off hours. During this process, Rob mentioned that in 2010 we'll begin to see some more integration with VMware and Hyper-V, as well as Quest's own Vizioncore product to aid in VM setup.

After the template was copied into vWorkspace, we installed the PNTools package, which is essentially the vWorkspace agent that helps the VM communicate with the broker and SCVMM. Normally, this would be built into the template, but we included it just to show the installation.

The next step as to set up a managed application in the computer group, which is essentially a published app. Since Quest treats VDI desktops as single-user terminal servers, this nomenclature makes sense. The "managed application" that we published in this situation is actually a desktop. After selecting to publish a desktop, you're asked if it is a TS published desktop or a Managed Computer Group desktop, so vWorkspace is aware of the difference, but it's not worth creating a completely separate UI.

Most of the other settings that we saw for managed applications are the same as what can be configured at the computer group (desktop pool) level. If left blank at the managed application level, the computer group settings will take effect.

Now that we have a desktop pool created and a desktop published, we needed to configure the web portal. The first thing we do is point the web interface to the proper farm. After that, we configured authentication (domain, two factor, etc...), and pointed it to the connection broker. The last thing we did was to pre-configure some of the user experience items like device redirection, multimedia redirection, graphics acceleration, bitmap caching, and so on.

Finally, before moving on to WAN testing, we configured a client settings policy. A lot of these settings can be set elsewhere, but setting them in the policy allows you to cater to more client-specific needs. In our case, we deferred to the end user most of these settings so that we could control them during the WAN testing. The only thing we hard coded here was enabling bidirectional audio.

The user experience

As usual, the best way to get the user experience is to check out the video. We actually found a bug when using Win 7 clients to connect to Win 7 guests while using PowerPoint 2007 with the orange flower on a slide. Sounds pretty crazy, but it's true. For about an hour Friday afternoon, we worked with Rob and even a Quest developer to troubleshoot the problem. Turns out it has something to do with Graphics Acceleration and those specific circumstances. Using Windows XP as the client, for instance, worked just fine.

Anyway, check out the video to see what using RDP enhanced by EOP is like:

The Bottom Line

From Gabe:

From the video, it might seem that Quest is pretty complicated, but by and large I was pretty happy with the way the day went. Rob was more demonstrative than the other vendors during installation and configuration in an effort to show the individual features, but that shouldn't be a ding on complexity. In fact, Quest's solution is actually pretty robust, and the fact that they integrate with all the major virtualization platforms is a big positive when going into organizations that might like one vendor's hypervisor but not their VDI solution. I do wish that they had image sharing capabilities, but perhaps that's coming in a future release (please don't read anything into that...I know nothing in that regard).

I also wish that EOP demonstrated a little bit better performance. Having seen Microsoft earlier in the week, and knowing that EOP enhances RDP, I expected to see better performance than plain old RDP in similar situations. What we saw was that EOP's bitmap caching doesn't work the same way as RDP's, and that some of the newer settings in RDP (like whatever they do with the Satellite client hint) aren't available as options with vWorkspace yet. We've heard they will be in the next version, so I'm anxious to see what 7.1 looks like. We've already made tentative plans to bring Quest back when it comes out.

It wasn't all bad, though, and EOP does add some cool things like local text echo (which isn't all that common these days) and USB redirection. All in all, it was a positive user experience, but with room for improvement.

From Brian:

I've always had a soft spot for Quest (well, Provision Networks originally). These were the folks who finally convinced me that VDI could make sense (since they view a VDI instance as nothing more than a single-user Terminal Server and they manage it as such).

Quest's vWorkspace is pretty straightforward and flexible.. It doesn't have as many features as XenDesktop (Quest is host-based only and doesn't have any built-in disk image sharing or app virtualization), but it's more flexible and more granularly-controllable (is that a word?) than VMware View or Virtual Bridges VERDE).

I understand that Quest will soon be releasing some more protocol enhancements.. It's too bad that we couldn't test with those, because I wasn't super blown-away by EOP. (Although I like that Quest adds stuff like USB redirection.) And I'm happy that they'll also support RemoteFX when it's out.

To use Quest at scale, you'll need third-party VM management software, like SCVMM for Hyper-V or vCenter for ESX. And you'll need to bring your own disk imaging and app virtualization capabilities. But I like that Quest is an "engineer-driven" product that gives a lot of flexibility while hiding most of the crazy complexity (something XenDesktop fails at). Overall it's easy to understand why there are a lot of Quest fans in the world.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

vWorkspace and Windows 7 clients is a bug with anything, not just PPT


Oh yeah? What else have you seen? I guarantee Quest is watching this thread.


The bug is actually in just our Graphics Acceleration option that I had not unchecked from an earlier test.  For managed desktops (like what we were showing here)  GA is not always the best option and is actually disabled when Aero (Desktop Composition is turned on)...

While it IS a bug, unchecking the Graphics Accleration solved the problem and is being looked at by dev...



Thanks guys!

With Quest being a bit of black hole in my knowledge in recent years this geek day was really useful. The presentation was well done (thanks Rob). While I cannot quite comment on the results (black hole, remember) I do fancy the architectural desingn.

With all this and as this geek week ends, can we please have some prel. RemoteFX comments + the obvious lackluster WAN delivery in the overall delivery model. To clarify. I see VDI as a LAN restricted solution - nothing bad with that per. se. but I kinda wonder about the reach out for WAN. I cannot see it there. Comments?



Thanks for the comments...

While the WAN test did not go as planned I would give 7.1 a chance when it is released in the very near future.  We are adding the Satellite hints and some other very cool stuff around RDP/EOP over the WAN user a much richer experience.

As for the RemoteFX stuff we already came out with our release stating support for RemoteFX within 30 days once its been released... I can just say that we will not disappoint the early adopters in the RemoteFX area...



thanks for the comments...

When v7.1 is released in the near future we will be utilizing the RDP hints that MSFT used in their testing.  Our web interface and app portal don't have those but they are coming very soon...

The RemoteFX stuff is super exciting and we have already announced support within 30 days of it being released.  Let me just say we won't disappoint those early adopters...  




What solves the problem with seamless TS apps on Windows 7 clients running at 16 colors, random clipping and screens not being repainted properly?  Also a confirmed bug....


We take any/every issue seen and prioritize it. I would be willing to bet that it will be resolved with 7.1 if not already available for customers on a per incident basis..

v7.0 was our first release with Win7 support so there were bound to a few bugs...  I am sure you have been around software long enough to know how things work..  

I think Quest's track record of supporting their customers is right up there with any other software company....





Windows 7 support came out with v7 of vWorkspace in mid December.  As with any software release there will be things that are found after it goes out the door.

It really is not the fact software has a bug (all software has bugs) but how the company manages their customers over time.. We don't get folks coming back for other products and more of the same by not addressing issues..  




@Tony, Try turning aero off. I encounter similar problems with desktop sharing applications like Cisco meeting place, Sunbelt and some older apps from TS in seamless windows when using aero on the client.

The underpinning cause should still be solved but this might function in the interim.


@ Tony, Aaron & Rob - It's my understanding that the seamless issues (that I know of) when the client is Win7 or 2008 R2, have been resolved and you'll see them in 7.1. I saw emails from QA going back and forth about this a few weeks ago.  Aaron does mention a workaround, but we needed to have a hands-off fix where it just works.  The issue I'm most familiar with is seamless apps getting stuck in their original position on the screen.  

In 7.1 we can also set the client hints in Web Access and via the global config.xml file, so administrators don't have to rely on end users selecting the correct settings.  As with everything, we try to make the client as zero-touch as possible,

Aaron, I'm looking forward to coming down to Louisiana to see you on May 3rd when we'll get 7.1 installed for you.


@Patrick Rouse hypervguy.  Thanks for the info regarding 7.1 however if I can weigh in....I'm a fan of vWorkspace but I have issues with your QA and marketing in general.  7.0 was advertised with Windows 7 support and while "some" features are supported with Windows 7 and 2008 R2 (specifically around 64but support) some of the more basic features do not work, like TS clients (yes the app getting stuck in its position is one of them)  Also released in 7.0 was NetApp FlexClone capabilities  which in my testing is flaky at best.  When speaking to support about it, I got responses like "Can you reboot your NetApp?" and "I don't have a NetApp in the lab to test".  Which tells me these new features were hardly tested in QA before released and will be fixed in 7.1.

These type of situations makes me question statements from Quest that RemoteFX support will be available within 30 days of it's release.  Does that mean some half-working solution will be made 30 days after and a .1 release will fix it where it's actually usable in production?

I don't mean to rip on Quest or vWorkspace, like I said, I'm a big fan of the product, but vWorkspace disappoints as a Citrix alternative and I keep finding myself having to go back to Citrix time and time again.  No one gets fired for buying Cisco, EMC or Citrix....


Just to clarify, the issues with remote desktop sharing software (Meeting Place, sunbelt etc) were while running locally. Have nothing to do with TS or vWorkspace except that they have similar symptoms.


It's a good product but sometimes I think they are going backwards.  With 5.9 if VC was unavailable their would be no impact to VM's.  with 6.2 and newer if VC is unavailable the VM's are placed offline which really sucks.


RDP sucks, everybody knows it, and it will continue to suck for WAN use cases. MS will not invest to attack their rich client monopoly and Quest does not have the $$$ to make it work. Lipstick on a pig, MS marketing and VMWare woke up and decided they had to find something better, and it is at 20X the bandwidth. If a protocol was that easy everybody would do it. Oh they are trying, but how many more years will people continue to fail. I hope they don't because only them will Citrix be forced to make ICA a standard for everybody and open up competition.