In Windows Server 2008 R2 (WS2008R2), Terminal Services (TS) has been expanded and renamed to Remote Desktop Services (RDS). RDS is the backbone of Microsoft's VDI solutions. And in Windows Server 2012, RDS is further enhanced and with a scenario-based configuration wizard. Still the concept and architecture remain very much the same since WS2008R2. The new and enhanced architecture takes advantage of virtualization and makes remote access a much flexible solution with new deployment scenarios. To realize the capabilities of RDS, it is essential to understand the functions of key architectural components and how they complement one another to process a RDS request. There are many new terms and acronyms to get familiar with in the context of RDS. For the remainder of this post, notice RDS implies the server platform of WS2008R2 and later, while TS implies WS2008.
There are five main architectural components in RDS, as shown, and all require a RDS licensing server. Each component includes a set of features designed to achieve particular functions. Together, the five form a framework for accessing Terminal Services applications, remote desktops, and virtual desktops all with WS2008R2 capabilities. Essentially, WS2008R2 offers a set of building blocks with essential functions for constructing enterprise remote access infrastructure.
To start, a user will access a RDS webpage by specifying an URL where RDS resources are published to. This interface, provided by Remote Desktop Web Access (RDWA) and configured with a local IIS with SSL, is the web access point to RemoteApp and VDI. The URL is consistent regardless how resources are organized, composed, and published from multiple RDS session hosts behind the scene. By default, RDS publishes resources at https://the-FQDN-of-a-RDWA-server/rdweb and this URL is the only information a system administrator needs to provide to a user for accessing authorized resources via RDS. A user will need to be authenticated with one’s AD credentials when accessing the URL and the RemoteApp programs presented by this URL is trimmed with access control list. Namely, an authenticated user will see and be able to access only authorized RemoteApp programs.
Remote Desktop Gateway (RDG) is optional and functions very much the same with that in TS. A RDG is to be placed at the edge of a corporate network to filter out incoming RDS requests by referencing criteria defined in a designated Network Policy Server (NPS). With a server certificate, RDG offers secure remote access to RDS infrastructure. As far as a system administrator is concerned, RDG is the boundary of a RDS network. There are two policies in NPS relevant to an associated RDG:
In RDS, applications are installed and published in a Remote Desktop Session Host (RDSH) similar to a TS Session Host, or simply a Terminal Server in a TS solution. A RDSH loads applications, crunches numbers, and produces results. It is our trusted and beloved working horse in a RDS solution. Digital signing can be easily enabled in a RDSH with a certificate. Multiple RDSHs can be deployed along with a load balancing technology. Which requires every RDSH in a load-balancing group to be identically configured with the same applications.
A noticeable enhancement in RDSH (as compared with TS Session Host) is the ability to trim the presence of a published application based on the access control list (ACL) of the application. An authorized user will see, hence have an access to, only published applications of which the user is included in the ACL. By default, the Everyone group is authorized in a published application’s ACL, and all connected user will have access to a published application.
Remote Desktop Virtualization Host (RDVH) is a new feature which serves requests for virtual desktops running in virtual machines, or VMs. A RDVH server is a Hyper-V based host, for instance a Windows Server with Hyper-V server role enabled. When serving a VM-based request, an associated RDVH will automatically start an intended VM, if the VM is not already running. And a user will always be prompted for credentials when accessing a virtual desktop. However, a RDVH does not directly accept connection requests and it uses a designated RDSH as a “redirector” for serving VM-based requests. The pairing of a RDVH and its redirector is defined in Remote Desktop Connection Broker (RDCB) when adding a RDVH as a resource.
Remote Desktop Connection Broker (RDCB), an expansion of the Terminal Services Session Broker in TS, provides a unified experience for setting up user access to traditional TS applications and virtual machine (VM)-based virtual desktops. Here, a virtual desktop can be running in either a designated VM, or a VM dynamically picked based on load balancing from a defined VM pool. A system administrator will use the RDCB console, called Remote Desktop Connection Manager, to include RDSHs, TS Servers, and RDVHs such that those applications published by the RDSHs and TS Servers, and those VMs running in RDVHs can be later composed and presented to users with a consistent URL by RDWA. And with this consistent URL, authenticated users can access authorized RemoteApp programs and virtual desktops.
A Remote Desktop (RD) Client gets connection information from the RDWA server in a RDS solution. If a RD client is outside of a corporate network, the client connects through a RDG. If a RD client is internal, the client can then directly connect to an intended RDSH or RDVH once RDCB provides the connection information. In both cases, RDCB plays a central role to make sure a client gets connected to a correct resource. With certificates, a system administrator can configure digital signing and single sign-on among RDS components to provide a great user experience with high security.
Conceptually, RDCB is the chief intelligence and operation officer of a RDS solution and knows which is where, whom to talk to, and what to do with a RDS request. Before a logical connection can be established between a client and a target RDSH or RDVH, RDCB acts as a go-between passing and forwarding pertinent information to and from associated parties when serving a RDS request. From a 50,000-foot view, a remote client uses RDWA/RDG to obtain access to a target RDSH or RDVH, while RDCB connects the client to a session on the target RDSH, or an intended VM configured in a target RDVH. Above is a RDS architecture poster with visual presentation on how all flow together. Http://aka.ms/free has number of free e-books and this poster for additional information of WS2008R2 Active Directory, RDS, and other components.
The configuration in WS2008 is a bit challenging with many details easily overlooked. Windows Server 2012 has greatly improved the user experience by facilitating the configuration processes with a scenario-based wizard. Stay tuned and I will further discuss this in an upcoming blog post series.
Recommended additional reading on RDS/VDI/App-V, cloud essentials, and private cloud
This is a follow-up posting and a continual discussion of desktop virtualization and Remote Desktop Services (RDS) relevant to Windows 7 and Windows Server 2008 R2 (WS2008R2). I highly recommend those who are not familiar with RDS taking a moment to review the architecture and know what role RDWA, RDG, RDSH, RDVH, and RDCB each is playing in serving a remote access request. Which will facilitate one’s understanding of the integration between RDS and VDI, and sets the stage for the next level of discussion in my upcoming post to go over the nuts and bolts of building a VDI solution. I wrote this article with the following logical flow in mind:
What It Is
A centralized desktop delivery solution, Microsoft Virtual Desktop Infrastructure (VDI) is. The concept of VDI is to store and run desktop workloads including a Windows client operating system, applications, and data in a server-based virtual machine (VM) in a data center and allow a user to interact with the desktop presented onto a user device via Remote Desktop Protocol (RDP). Notice VDI is part of an enterprise’s cohesive, holistic virtualization strategy across IT infrastructure to support Microsoft’s vision of Dynamic IT. VDI is not an isolated architecture, but one of the many technologies available to optimize enterprise desktops.
User Experience
A noticeable component in the Remote Desktop Services (RDS) of WS2008R2 is the availability of Remote Desktop Connection Broker (RDCB). RDCB is a native VDI connection broker to provide a unified experience for access to VDI as well as traditional session-based remote desktops. With RDCB, virtual desktops are now delivered similar to RemoteApp. For example, a user will access http://rds-all.contoso.corp/rdweb and be presented with a webpage with authorized applications and desktops, once authenticated, as shown below.
Here, three Office 2007 applications are published as RemoteApp which works very much the same with that in Windows Server 2008. In Windows Server 2008 R2 however, RemoteApp programs shown on this consistent URL can be composed from multiple sources. The RemoteApp programs shown here are not necessarily installed on the same Remote Desktop Session Host (RDSH) or Terminal Server. They can be from multiple RDSHs and Terminal Servers, yet composed and presented with the same URL. Further, the presence of a RemoteApp program is based on the access control list of a published application in RDSH. By default, all authenticated users will have access to published RemoteApp programs.
The icon, My Desktop, appears for only those who are assigned with a personal virtual desktop. The assignment can be done in RDCB, or the User object in Active Directory. When a user click My Desktop icon, a virtual desktop will be delivered to the user’s device, once the user is authenticated. The follow screen capture shows Word 2007 accessed as a RemoteApp program and a virtual desktop delivered via VDI to a user on a non-managed Windows 7 client.
The icon, Contoso Desktop, is for accessing a virtual desktop running on a VM dynamically picked from a VM pool defied in RDCB. Notice once a VM pool is defined, the icon to access a VM in the pool will show up on the RDS webpage for all authenticated users, regardless if a user has access to the pool. Both the display name of the page and the display name of the icon to access a VM pool can be easily customized in RDCB, here “Contoso Wonder LAN” and “Contoso Desktop” are both customized display names. Further information of the RDS architecture and how RDCB plays a central role in a VDI solution is available in “Remote Desktop Services (RDS) Architecture Explained.”
RemoteApp and Desktop Connection
A new feature in WS2008R2 worth mentioning here is RemoteApp and Desktop Connection which provides the ability to access to RemoteApp programs, remote desktops, and virtual desktops from the Start menu of a Windows 7 PC. In Windows 7, a user can go to Control Panel to configure it with a few mouse clicks in a friendly wizard-driven process. The URL of an intended RDS webpage and user credentials of an intended user are needed to complete the process. When RemoteApp and Desktop Connection accessing a target RDS webpage on a user’s behalf, the user will be prompted for credentials. The screen capture on the right shows the Widows 7 Start menu integrated with RDS resources published on the Contoso Wonder LAN page shown earlier. If the user deletes the settings configured in RemoteAll and Desktop Connection, the Contoso Wonder LAN and its content will be removed accordingly.
To facilitate RDS/VDI deployment, an enterprise administrator can create and distribute a client configuration (.wcx) file to a user to facilitate configuring RemoteApp and Desktop Connection. Another way is to distribute a script to run the client configuration file silently, so that RemoteApp and Desktop Connection is set up automatically when a user logs on to their account on a Windows 7 computer. The automation can be easily done, minimize operator intervention, and provide a great user experience.
With RemoteApp and Desktop Connection, a Windows 7 user can access RemoteApp programs and virtual desktops directly from the Start menu without the need to specify the RDS URL. This minimizes the user training and offers a consistent user experience on using Windows applications.
How It Works
With VDI, a virtual desktop is isolated from the client’s device and runs in a VM maintained in a data center. Here the device can be a desktop, laptop or thin client. A VDI user interacts with one’s virtual desktop through RDP which provides a rich desktop experience. Similar to session-based remote desktops (formerly known as Terminal Services), VDI provides a server session with a full-fidelity desktop environment that is virtualized within a server-based hypervisor. The premise on VDI is that all VDI users are running virtual desktops on VMs. Key technical components making VDI a reality include:
In a VDI deployment, there are two models: (1) a static or persistent virtual desktop and (2) a dynamic or non-persistent one. In static mode, there is a one-to-one mapping of VMs to users. Each user is assigned with a designated VM. Since VMs are commonly stored on a Storage Area Network (SAN) and execute on a server, a larger number of users will likely lead to significant SAN requirements.
In a dynamic architecture, on the other hand, there is only one master image of the desktop stored. All user personalization, profile, applications, etc. are stored separately from the desktop. When a user requests a desktop, a VM cloned from the master image is combined with the user’s personal data and applications dynamically delivered to the user device based on roaming profiles and App-V. This delivers a personalized desktop experience by dynamically provisioning a base image. it simplifies the overall VM management by reducing the number of desktop images maintained.
Considerations
Both RDS and VDI are core components of desktop virtualization, and they satisfy specific computing requirements and scenarios with deployment readiness and flexibility. For a remote task worker who needs to access a specific application for carrying out a well-defined task like entering data or reporting a status for time reporting, inventory update, or incident reports, etc. RemoteApp may be sufficient. A knowledge worker, on the other hand, who performs complex or unstructured routines like analyzing data, architecting a solution, design a product, writing code, troubleshooting system, etc. will likely require full access to a desktop to assure productivity, and deploying a virtual desktop is one solution.
Notice that VDI, while flexible, does require more server hardware resources than the traditional session-based remote desktop approach. In general, VDI requires an upfront investment in server and storage hardware to store and execute all needed VMs. To ensure users able to access virtual desktops, the network supporting VDI needs highly available since for a user, no network connectivity, no virtual desktop accessible. Generally speaking, the network bandwidth requirement is also expected relatively higher to support VDI than that supports Terminal Services. Virtual machine management software is also essential to manage enterprise virtual desktops, i.e. VMs, running in hypervisor hosts. On user experience, one should not expect a remote desktop or a virtual desktop to perform exactly as well as a locally installed desktop. Audio, video, and USB performance on a remote desktop may not be as rich as those directly running on or attaching to a user’s device. The fact is a rich client will always provide a superior user experience to that delivered with VDI. Overall, considerations of a Microsoft VDI solution should include, but not be limited to:
VDI Licensing
VDI essentially delivers a desktop on demand to a user device via a network connection. This is different from running a conventional desktop machine with which an OEM license is bound to hardware and cannot be dynamically assigned as VDI does. The traditional licensing has become insufficient to correctly reflect the number of licenses consumed in a desktop deployment delivered with VDI.
To accommodate new deployment scenarios, Microsoft has introduced two new offerings for VDI: Microsoft Virtual Desktop Infrastructure Standard Suite (VDI Standard Suite) and Microsoft Virtual Desktop Infrastructure Premium Suite (VDI Premium Suite). Both the VDI Standard Suite and the VDI Premium Suite are licensed per client device that accesses VDI environment, and thereby allow for flexibility of server infrastructure design and growth. Additional information on Remote Desktop Services Licensing is available.
RDS vs. VDI
Like many solutions, there are pros and cons in employing RDS or VDI, as shown below. And in my view, just like the debates on ”thick client vs. thin client” and “in the cloud vs. on premises,” I have no doubt there will also be a mix of the two, RDS and VDI, in enterprise IT in a foreseeable future. I believe what we must recognize is that business requirements should dictate a solution chosen.
Why VDI
Since virtual desktops delivered by VDI are VMs running in a data center, enterprise IT can realize all the benefits of centralized desktop management. Strategically, VDI enables enterprise IT to
VDI is not for every user but provides deployment readiness and flexibility for specific scenarios including:
Best Practices for VDI
Segment desktop users and categorize user requirements to better understand user scenarios. Assess who can benefit from centralized desktops, and with what kind of business benefits.
Centralizing desktops can be implemented using RDS, VDI, or a combination of the two. And user requirements should determine which is best fit.
Separate applications from desktop image, dynamically provision desktop applications based on user, and minimize the number of desktop image. One solution is to employ Microsoft App-V/TS or App-V for Terminal Services with a VDI solution. Further discussion of App-V/TS will be in my upcoming blog and beyond scope of this article.
Closing Thoughts
We must be aware that running virtual desktops does not eliminate licenses or IT management costs. And it may be a challenge to prove the TCO reduction with an emerging technology like VDI which uplifts IT’s capabilities to a new dimension by fundamentally changes how desktops and applications can be deployed and managed like a service using virtualization.
“Service” sometimes can be a very scary term. For decades, enterprise IT has been delivering services to its customers. Today, we are still learning and debating how to quantify and put a business value to IT services. VDI, in my view, is a service and I am almost hearing “everything as a service” now. To ensure a success and realize business benefits of a VDI solution, a baseline is integral and should be first established. As discussed earlier, VDI works well for some scenarios, and there are times VDI may not be the most cost-effective way, nevertheless it is a solution with most predictability to succeed. The key is to be clear on what a VDI solution is trying to achieve and, as critical, identify: what to measure, where to draw a line, and on which direction an organization is heading. Although it sounds a common sense and like project management 101, in a VDI project basics are critical. And I here predict:
I have already seen VDI and other virtualization technologies like App-V and RDS bringing new opportunities and challenges to many of us. Going forward I believe VDI will continue having an impact on how you, I, and organizations perceive IT and carry out an IT business. As cliché as it sounds, this is an IT transformation from an infrastructure-focused deployment to physical devices into a dynamic and user-centric approach with virtual desktops. Perhaps, this is what I am really saying:
This is a follow-up posting of Windows 7 BranchCache™ Explained.
BranchCache, an exciting feature introduced in Windows 7 and Windows Server 2008 R2, enables content from file and Web servers on a wide area network (WAN) to be cached on computers at a local branch office. Once BranchCache is configured, a copy of data accessed from intranet Web and file servers is cached locally within the branch office. Cached content can either be distributed across peer client computers (Distributed Cache mode) or centrally hosted on a server (Hosted Cache mode). When another client on the same network requests the file, the client downloads it from the local cache without downloading the same content across the WAN. BranchCache is to improve application response time and reduce WAN traffic.
Specifically BranchCache, as shown below, has two operating modes: Hosted Cache mode and Distributed Cache mode. Hosted Cache mode specifies a local server for caching content downloaded form a content server over the WAN. Caching occurs at the very first request from a user in a branch office. A user from the same branch office subsequently requests for the same content will establish a connection with and retrieve the cached content from the local Hosted Cache server. Host Cache mode is recommended for a branch with more than 50 clients and does require some form of infrastructure for caching and accessing the content in a local server.
Distributed Cache mode, on the other hand, is for a small branch without a local file server that can be used as a hosted cache server. This configuration caches content downloaded from a content server over the WAN at a user’s computer. Caching occurs at the very first request from a user in a branch office. A user from the same branch office subsequently requests for the same content will locate the cached content by broadcasting, and then retrieve the content from that user’s computer in the local area network. Peer-to-peer sharing is the basic idea. There is no central repository in the branch. There are no requirements for servers or services in the branch office beyond client computers running Windows 7.
Hosted Cache mode is different from the Distributed Cache Mode process since:
This screencast walked through the steps to configure and demonstrate BranchCache Hosted Cache mode with a simulated WAN environment. All virtual machines used in the screencast were running in one hard disk of a laptop with 8 GB of RAM running Windows Server 2008 R2 with Hyper-V enabled.
Additional information:
For those who would like to try and get familiar with Windows 7 and Windows Server 2008 R2, follow the following links to download, install, and test it out. Here I also include the download information of Forefront and System Center which are essential for securing and managing enterprise infrastructure.
(This is a cross-posting from Windows Server Expert Blogs)
The US TechNet events for this quarter are open for registration. There are: one focus – you; two presenters - the good and the better looking, not listed in order however; and three topics - Azure, Hyper-V, and Windows 7 deployment. There will be a lot of fun, serious learning, and geeky conversations. You do not want to miss it.
Call to Action
If you would like to subscribe TechNet Plus, do not pay the full price now. Go to the personal blog of or simply email your regional IT Pro Evangelist and look for a promotion code (for instance, TNITE10) to get 28% off. This promotion is good till 03/31/2010.
For US east region, here is a list for all scheduled events. Click the city name to link to registration page and the speaker name to one’s personal blog. Look forward to seeing you all.
TechNet US East Region Events
State - City
Date
Speakers
PA - Philadelphia
Tuesday, February 23, 2010
Yung Chou,
Bob Hunt
VA - McLean
Thursday, February 25, 2010
GA - Alpharetta
John Baker,
Dan Stolts
NJ - Edison
Tuesday, March 02, 2010
Bob Hunt,
NC - Raleigh
Wednesday, March 03, 2010
John Baker
NC - Charlotte
Friday, March 05, 2010
FL - Orlando
Tuesday, March 09, 2010
Blain Barton,
MD - Towson
Wednesday, March 10, 2010
FL - Ft. Lauderdale
Thursday, March 11, 2010
NY - Troy
Friday, March 12, 2010
Dan Stolts,
PA - Pittsburgh
Tuesday, March 16, 2010
MD - Chevy Chase
Tuesday, March 23, 2010
Blain Barton
MA - Waltham
Wednesday, March 24, 2010
NY - New York City
Thursday, March 25, 2010
CT - Farmington
Friday, March 26, 2010
January, 2010 - Yung Chou on Hybrid Cloud - Site Home - TechNet Blogs