Microsoft's Remote Desktop Service broker now supports both standard Remote Desktop Service (RDS) sessions and connections to virtual desktops. Sadly, the broker does not facilitate the process of creating and provisioning new virtual desktops; an essential component for virtualizing desktops.
First, the broker must advertise the desktop to the user's client using group membership from Active Directory. Then it must establish a connection that can traverse a secure firewall with some DMZ-located "gateway." Finally, the broker should make it easy to deploy new desktops.
The Microsoft RDS broker succeeds on the first two, but not the last.
Where Microsoft RDS falls short
Right now, Microsoft is focused on using storage-array tools such as NetApp's VSC (Virtual Storage Console, formerly called the Rapid Clone Utility, or RCU) to generate desktop pools. In the long term, that's the direction other vendors are going, as demonstrated by VMware's recent vStorage APIs for Array Integration (VAAI) application programming interface (API) initiative.
However, in the interim, array vendor cloning is a feature that requires a license -- and it excludes the use of local storage. On the upside, some Microsoft customers have been able to develop cloning scripts using Hyper-V's PowerShell support. But if customers are doing this, there is a need that the product doesn’t fulfill. Microsoft could do a better job here, especially with that other technology that is so closely tied to mass deployments of duplicated images -- Sysprep.
Sysprep is the real elephant in the room of desktop deployments, both physical and virtual. At best, Sysprep is slow and bedeviled with unfathomable "features." I prefer VMware's "QuickPrep" method, which ships with VMware Composer's linked clones feature.
With QuickPrep, a domain account is used to prepopulate Active Directory with computer accounts. An added benefit is that they aren't unceremoniously dumped in the "computers" container but are created in the organizational unit (OU) you specify.
Using Microsoft's approach, once a virtual desktop is created, the assignment of the user to the desktop is held in Active Directory. This could cause problems for some Windows shops because human resources departments often don't inform the IT department when a user leaves an organization. How many virtual desktops might end up just sitting there with nobody using them?
That takes us to the latest VDI technology in Microsoft's armory: RemoteFX, which is designed to deliver an ultra-rich graphics experience for applications such as computer-aided design and 3-D rendering.
Before learning all about this technology, I lumped it in with Citrix HDX and VMware PC over IP (PCoIP). That was a mistake.
Both Citrix and VMware claim that their new protocols are fit for the wide area network (WAN), but Microsoft opted for a more conservative approach than WAN delivery.
The company designed its new remote display protocol for local area network (LAN) delivery and is targeting customers who adopted blade PCs, HP's Remote Graphics Display or Teradici.
My friends out in the field say the advances of HDX over ICA have been wildly exaggerated. Similarly, PCoIP has been successfully used across the WAN, but the amount of bandwidth required to deliver a rich graphics experience has been obscured. Both HDX and PCoIP default to a lossy mode as soon as bandwidth or latency dips below a certain level. IT might promise users a super-rich graphics experience, but it could ultimately be rendered down to something more akin to ICA or RDP.
RemoteFX, part of Windows Server 2008 R2 Service Pack 1, is also going to have very strict graphics requirements. For example, a virtual desktop session with one monitor at 1024x768 would eat 75 MB of graphics RAM, whereas at 1900x1200, it demands 220 MB. If using multiple monitors, you could need an additional 50 MB to100 MB per session.
These big RAM requirements limit the scalability of RemoteFX, and I think that's why Microsoft is pitching it as niche solution rather than a general-purpose protocol. Graphics cards with gigabytes of RAM on them are possible, but talk of them makes me feel that we have drifted away from the 640 KB of RAM that would have been enough some years ago.
ABOUT THE AUTHOR:
Mike Laverick is a professional instructor with 15 years of experience in technologies such as Novell, Windows and Citrix. He has also been involved with the VMware community since 2003. Laverick is a VMware forum moderator and member of the London VMware User Group Steering Committee. In addition to teaching, Laverick is the owner and author of the virtualization website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users. In 2009, Laverick received the VMware vExpert award and helped found the Irish and Scottish user groups. Laverick has had books published on VMware Virtual Infrastructure 3, VMware vSphere4 and VMware Site Recovery Manager.
This was first published in January 2011