by
Gabe Knuth
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.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.