Hide Notes 

Slide 1: Technical Overview of Windows Server® 2008 R2 Remote Desktop Services Microsoft Corporation Published: May 2009 Abstract Windows Server® 2008 R2 Remote Desktop Services (RDS) enables organizations of all sizes to provide user access to Windows®-based applications and desktops stored on a remote computer over a network. With RDS, only the user interface (UI) of an application or remote desktop is presented on the client computer. Any input to it is redirected over the network to the RDS server back end, where all processing occurs. This technical white paper discusses the features, benefits, and usage scenarios for RDS and is intended for server administrators who are already familiar with RDS as well as those server administrators who want to learn more about Microsoft’s desktop and presentation virtualization technologies.
Slide 2: Disclaimer The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. ©2009 Microsoft Corporation. All rights reserved. Microsoft, Access, Active Directory, Aero, DirextX, Excel, Hyper-V, Powerpoint, PowerShell, RemoteApp, Silverlight, SharePoint, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. ii
Slide 3: Table of Contents Disclaimer.................................................................................................................................................. ii Table of Contents ......................................................................................................................................... iii Remote Desktop Services Architecture ........................................................................................................ 1 Remote Desktp Session Host .................................................................................................................... 2 Remote Desktop Virtualization Host......................................................................................................... 2 Centralized Desktop Architecture ............................................................................................................. 3 What’s New in Remote Desktop Services ..................................................................................................... 5 RDSH Server / RDVH Server ...................................................................................................................... 6 RD Connection Broker............................................................................................................................... 7 RD Gateway............................................................................................................................................... 8 RD Web Access.......................................................................................................................................... 9 RD Licensing ............................................................................................................................................ 10 Support for the Virtual Desktop Infrastructure ...................................................................................... 11 Full-Fidelity User Experience....................................................................................................................... 13 Remote Application Access ..................................................................................................................... 13 New Management Features ....................................................................................................................... 14 Roaming User Profile Cache Management ............................................................................................. 14 Fair Share CPU Scheduling ...................................................................................................................... 14 Application Compatibility............................................................................................................................ 16 Remote Desktop IP Virtualization ........................................................................................................... 16 Windows Installer RDS Compatibility ..................................................................................................... 16 At-a-Glance Feature Comparison by Version.............................................................................................. 18 RDS Scenarios.............................................................................................................................................. 20 User Scenarios......................................................................................................................................... 20 Administrator Scenarios.......................................................................................................................... 21 Planning for Windows Server 2008 R2 RDS ................................................................................................ 22 Key Differences Between RDSH Servers and RDVH Servers ................................................................... 22 Piloting RDVH Server ............................................................................................................................... 23 User Applications .................................................................................................................................... 26 Virtual Machine Preparation................................................................................................................... 27 iii
Slide 4: User State................................................................................................................................................ 28 Network .................................................................................................................................................. 29 Better Together: App-V and RDS ................................................................................................................ 31 App-V for RDS: Features and Benefits .................................................................................................... 31 Summary ..................................................................................................................................................... 33 iv
Slide 5: Remote Desktop Services Architecture The Windows Server® 2008 R2 Remote Desktop Services (RDS) architecture consists of the following components:     RD Session Host (RDSH) Server and/or RD Virtualization Host (RDVH) Server RD Licensing RD Gateway RD Connection Broker  RD Web Access Figure 1 shows a simple RDS deployment scenario, highlighting the relationships among the different components. Key points to note are:    The remote client uses the RD Gateway to obtain access to the RDSH Server and the RDVH Server. The RD Connection Broker connects clients to sessions and virtual machines (VMs) on the RDSH Server and the RDVH Server. All Remote Desktop Servers require validation with an RD Licensing Server. Figure 1. Simple RDS deployment 1
Slide 6: Remote Desktop Session Host (RDSH) RDSH Servers function like Terminal Services. Using the RD Connection Broker, RDSH Servers provide access to applications—either by providing access to the server’s desktop or by using RemoteApp™. In the event that RemoteApp is used, the RemoteApp and Desktop Connections feature can be used to distribute RemoteApp program links to Windows® 7 clients. Alternatively, clients can access remote desktops or RemoteApp applications through the RD Web Access interface. The RD Connection Broker connects clients evenly across an RDS application farm, as Figure 2 shows. Figure 1 Simple RDS application farm scenario Figure 2 also shows client access to a RDSH Server server farm hosting Microsoft® Office Word and Office Excel®. Each connection is routed to a different server. If the connection is lost, RD Connection Broker will reestablish the connection to the appropriate RDSH Server. Remote Desktop Virtualization Host (RDVH) The RD Virtualization infrastructure adds a new component required for proper functioning of the RDVH Server: the RD Redirector. The RD Redirector redirects RDP session to the appropriate RDVH Server by working in conjunction with the RD Connection Broker. Figure 3 shows the addition of an RD Redirector, providing connectivity to the RD Virtualization Host. 2
Slide 7: Figure 3. Adding an RD Redirector Centralized Desktop Architecture One of the key goals in deploying RDS is to centralize the execution and management of remote desktops and applications. Each technology presented—RDSH Server, RD Virtualization Host Server, RemoteApp, and Microsoft Application Virtualization (App-V)—provide technologies to centralize different aspects of a typical desktop load. To better understand the relationship among the different RDS components and how they fit in with a centralized desktop-management strategy, see Figure 4, which provides a high-level view of these interactions. 3
Slide 8: Figure 4. Centralized desktop architecture in the context of virtualization layers 4
Slide 9: What’s New in Remote Desktop Services Windows Server 2008 R2 Remote Desktop Services is the expansion of a group of services that focuses on delivering a highly interactive, full-featured desktop experience while maintaining strong administrative control over applications and desktop execution in a centralized location. RDS encompasses the roles formerly known under the Terminal Services workload as well as a new role service to manage and automate access to virtual desktops based on Hyper-V™ technology for a Virtual Desktop Infrastructure (VDI). Combined, these services are now called Remote Desktop Services. For Windows Server 2008 R2, the following features have been added or enhanced:  Windows Server 2008 R2 only supports 64-bit processors. With the introduction of Windows Server 2008 R2, the Windows Server operating system is compatible only with 64-bit processor architectures, which allows access to much more system memory. This requirement in turn allows the operating system and applications running on the server to be much more flexible and equitable with memory management, enabling more users per server. Terminal Services name change. RDS, formerly Terminal Services, in the Windows Server 2008 R2 operating system provides technologies that enable users to access sessionbased desktops, VM-based desktops, or applications in the data center from within a corporate network or from the Internet. RDS enables a full-fidelity desktop or application experience and efficiently connects remote workers from managed or unmanaged devices. In Windows Server 2008 R2, all RDS role services have been renamed. Table 1 lists both the former name and the new name in Windows Server 2008 R2 for each RDS role service. Table 1. RDS Role Service and feature Names Previous name Terminal Services Terminal server Terminal Services Licensing (TS Licensing) Terminal Services Gateway (TS Gateway) Terminal Services Session Broker (TS Session Broker) Terminal Services Easy Print (TS Easy Print) Terminal Services Web Access (TS Web Access) None – New in Windows Server 2008 R2 None – New in Windows Server 2008 R2 Name in Windows Server 2008 R2 Remote Desktop Services Remote Desktop Session Host Server (RDSH Server) Remote Desktop Licensing (RD Licensing) Remote Desktop Gateway (RD Gateway) Remote Desktop Connection Broker (RD Connection Broker) Remote Desktop Easy Print (RD Easy Print) Remote Desktop Web Access (RD Web Access) RemoteApp and Desktop Connections Remote Desktop Virtualization Host Server (RDVH Server)  In addition to the RDS role services names, the names of the RDS management tools have changed. Table 2 shows the former and new names. 5
Slide 10: Table 2. RDS Management Tool Names Previous name Terminal Services Manager Terminal Services Configuration TS Gateway Manager TS Licensing Manager TS RemoteApp® Manager Name in Windows Server 2008 R2 Remote Desktop Server Manager Remote Desktop Server Configuration Remote Desktop RD Gateway Manager Remote Desktop RD Licensing Manager RemoteApp Manager The following sections provide detailed information on key changes in RDS. Specifically covered in this section are RDSH Server, RD Licensing, RD Connection Broker, RD Gateway, and RD Web Access. Several areas of interest are discussed in depth in the second part of this document focusing on the RDS infrastructure. Remote Desktop Session Host (RDSH) Server RDSH Server replaces what was referred to as the terminal server role. In Windows Server 2008 R2, the RDSH Server role has been enhanced with the following improvements:  RDS includes several enhancements to the underlying services that provide increased performance to Remote Desktop sessions. These enhancements are applied at the kernel level and are geared toward increasing the distribution of processor time for each user. A scheduling algorithm fairly distributes processor cycles across sessions. The algorithm dynamically distributes cycles based on the number of active sessions and their load. Processor resources are shared on a per-central processing unit (CPU) basis, and each session gets a fraction of each CPU, which ensures that RDS takes advantage of multiple-core computing.   By default, all sessions have an equal weight and are given a processor quota. If threads in a given session exceed their session’s processor quota, they are interrupted and queued. If the processor finishes under-quota threads, it takes the highest-priority thread of the least overquota session. RDSH Server has also been enhanced with new management features:      The roaming user profile cache can be adjusted using Group Policy. There are now enhanced command-line management tools based on Windows PowerShell™. RDS has been updated to improve application compatibility when users access applications over a Remote Desktop connection. Virtual Internet Protocol (IP) assignment can allow sessions and applications to receive a dedicated or dynamic IP address. The Windows Installer service has been improved to allow for multiple users installing applications simultaneously.  6
Slide 11:   The applications published by the RemoteApp feature can be filtered by user displaying only the applications that user has permissions to run. RemoteApp applications will also intelligently reuse the sessions for applications that are hosted on the same RDSH server or farm. This feature is called RemoteApp Source Aggregation. Client Experience Improvements The client experience continues to improve. Terminal Services permitted redirection of the Windows Aero® experience to provide a desktop-like experience for terminal server clients. These improvements continue with RDSH Server:  New Client Experience Configuration page. This page is available during role service installation to enable administrators to easily turn on any of the available features automatically without a lot of manual configuration. Previously, this feature had to be enabled separately. This page centralizes the client experience configuration into Remote Desktop Server Manager; the client must be running Remote Desktop Connection (RDC) version 7.0. Audio and video playback redirection. Users can now redirect the audio and video output of their local computers to a Remote Desktop session. Improved remoting for all content types. For applications unable to use existing primitive-based redirection and the new Windows media redirection feature, bitmap acceleration in R2 has been significantly enhanced to enable the remoting of rich media content from Microsoft Silverlight™, and Flash. Support for bi-directional audio. Users can now redirect the output of an audio recording device, such as a microphone, from the local computer to a Remote Desktop session. Desktop composition. Users now have the user interface (UI) elements of the Windows Aero experience within their Remote Desktop session.     Note Configuring any of these features also installs the Desktop Experience role service and starts the Windows Audio service on the RDSH Server. For more information, see What’s New in Remote Desktop Services at http://technet.microsoft.com/en-us/library/dd560658.aspx. RD Connection Broker RD Connection Broker (formerly TS Session Broker) is used to provide users with access to remote desktop and RemoteApp application resources. For Windows 7 client devices, the RemoteApp and Desktop Connections feature provides a customized view of those remote resources to users, including RemoteApp programs, session-based remote desktops, and VM-based remote (virtual) desktops. RD Connection Broker supports load balancing as well as reconnection to existing sessions and remote desktops accessed by using RemoteApp and Desktop Connections. To configure which RemoteApp programs and remote desktops are available through RemoteApp and Desktop Connections, add the RD Connection Broker role service on a computer running Windows Server 2008 R2, and then use RD Connection Broker. 7
Slide 12: RD Connection Broker extends the TS Session Broker capabilities included in Windows Server 2008 by creating a unified administrative experience for traditional session-based remote desktops and VMbased remote desktops (virtual desktops). A VM-based remote desktop can be either a personal virtual desktop or part of a shared virtual pool. In the case of a personal virtual desktop, there is a one-to-one mapping of VMs to users. Each user is assigned a virtual desktop that can be personalized and customized. These changes are available to the user each time that that user logs on to his or her personal virtual desktop. For a shared virtual pool, a single image is replicated across many VMs. As users connect to the shared virtual pool, they are dynamically assigned a virtual desktop. Because users cannot be assigned the same virtual desktop when they reconnect, no personalization or customization made by that user is saved by default. RD Connection Broker reconnects a user to a session if he or she is disconnected. This works for virtual desktops and RDSH Server–based sessions. If the user was connected to a virtual pool, the user may be able to reconnect to the virtual desktop in the same state he or she left it depending on the policy that has been configured for automatic session logoff. RD Connection Broker also acts as an RDSH Server load balancing redirector, aggregating multiple RDSH Servers and managing user load across each server. For more information, see What’s New in Remote Desktop Services at http://technet.microsoft.com/en-us/library/dd560658.aspx. RD Gateway RD Gateway is a role service in the Remote Desktop Server role included with Windows Server 2008 R2 that allows authorized remote users to connect to resources on an internal network from any device connected to the Internet. The network resources can be a remote desktop running RemoteApp programs or computers with RDC enabled. RD Gateway uses the Remote Desktop Protocol (RDP) over Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) to establish a secure, encrypted connection between remote users on the Internet and the internal network resources. The improvements to the RD Gateway role service will be of interest to organizations that currently use or are interested in extending RDS to clients not directly connected to the corporate network. The following changes are available in Windows Server 2008 R2. Secure Device Redirection Enforcement An RD Gateway server running Windows Server 2008 R2 includes the option to allow Remote Desktop clients to connect only to RDSH Servers or RDVH Servers that support secure device redirection. RDC 7.0 is required for secure device redirection to be enforced by the Remote Desktop Server running Windows Server 2008 R2. Secure device redirection enforcement helps prevent malicious code on remote clients from overriding security that administrators set. In Windows Server 2008 R2, RDS endpoints will enforce the redirection policy configured by the gateway. Previously, a rogue client could attempt to connect directly to endpoints, potentially ignoring the RD Gateway’s configured redirection policy. Configurable Idle and Session Timeouts RD Gateway allows configuration of idle and session timeouts on the RD Gateway server. An idle timeout provides the ability to reclaim resources that inactive user sessions use without affecting the user’s 8
Slide 13: session or data, helping to free resources on the RD Gateway server. After being disconnected, the user will be able to reestablish the session using RDC. A session timeout provides the capability to periodically enforce new policies on active user connections, ensuring that any system changes to user properties, such as domain accounts, Remote Desktop Connection Authorization Policy (RD CAP) changes, or Remote Desktop Resource Authorization Policy (RD RAP) changes, are enforced on existing sessions. Configurable idle and session timeouts with RD Gateway help administrators gain better control on users who are connecting through RD Gateway. Timeouts allow administrators to reclaim resources from sessions not currently in use, helping to ensure that idle sessions are not wasting system resources. User properties that are changed can still be enforced for users accessing the system using Remote Desktop sessions. Background Session Authentication and Authorization If a configured session timeout has been reached, sessions for users whose property information has not changed are not affected, and authentication and authorization requests are sent in the background. Background authentication and authorization requests are done automatically and require no user interaction. Service and Content Messages Service and content messages can be added to RD Gateway in Windows Server 2008 R2 and displayed to the remote desktop user. Service messages can be used to inform users of server-maintenance issues such as shutdowns and restarts. Content messages can be used to display a logon notice to users before they gain access to remote resources or legal information that the Remote Desktop user must acknowledge before starting an RD Gateway session. RD Gateway can be configured to allow connections only from Remote Desktop clients that support consent and service messages. The Remote Desktop client must be running RDC 7.0 to connect using this setting. Messaging can be used to keep remote desktop clients more informed. Service messages can be used to inform uses of upcoming server downtimes. Consent messages can be used to display legal information that the remote desktop user must acknowledge before starting an RD Gateway session. For more information, see What’s New in Remote Desktop Services at http://technet.microsoft.com/en-us/library/dd560658.aspx. RD Web Access RD Web Access, formerly TS Web Access, enables users to access remote resources such as sessionbased remote desktops, session-based remote applications, or VM-based remote desktops through a Web browser. RD Web Access provides a customized view of RemoteApp programs and remote desktops to users. When a user starts a RemoteApp program, an RDS session is started on the RDSH Server that hosts the RemoteApp program. If a user connects to a virtual desktop, an RDC is made to 9
Slide 14: either a VM that is running on an RDVH Server or to a desktop on an RDSH Server. To configure which RemoteApp programs and remote desktops are available through RD Web Access, add the RD Connection Broker role service on a computer running Windows Server 2008 R2, and then use RD Connection Broker. For more information, see Remote Desktop Web Access at http://technet.microsoft.com/enus/library/dd560668.aspx. RD Licensing The RD Licensing (formerly TS Licensing) role service manages the RDS client access licenses (RDS-CALs) required for each device or user to connect to an RDSH or RDVH Server. Use RD Licensing to install, issue, and track the availability of RDS-CALs on an RD Licensing server. Note No new CAL is required for Windows Server 2008 R2; both Windows Server 2008 TS-CALs and Windows Server 2008 R2 RDS-CALs will provide the right to connect to Windows Server 2008 R2. However, Windows Server 2008 SP2 is required to install RDS-CALs on Windows Server 2008 R2 Licensing Server; as such, Microsoft recommends installing a Windows Server 2008 R2 License Server. The following changes are available in Windows Server 2008 R2:    Automatic license server discovery no longer supported for RDSH Server Changes to the Licensing tab in Remote Desktop Server Configuration Manage RDS-CALs Wizard  Service connection point (SCP) registration The improvements to the RD Licensing role service will be of interest to organizations that currently use or are interested in deploying RDS in their environment. Automatic License Server Discovery No Longer Supported for Remote Desktop Servers In Windows Server 2008 R2, administrators must specify the name of a license server for the RDSH Server to use by using Remote Desktop Server Configuration. Prior to Windows Server 2008 R2, the license server was automatically discovered on the network. This discovery is no longer supported for an RDSH Server that is running Windows Server 2008 R2. Changes to the Licensing Tab in Remote Desktop Server Configuration In Remote Desktop Server Configuration in Windows Server 2008 R2, administrators must specify a license server for the RDSH Server to use. An administrator can either choose from a list of known license servers or manually enter the name. License servers that are registered as a service connection point in Active Directory® Domain Services (AD DS) will appear in the list of known license servers in Remote Desktop Server Configuration. More than one license server can be added for the RDSH Server to use. If more than one license server is added, the RDSH Server contacts the license servers in the order in which they appear in the Specified license servers box on the Licensing tab in Remote Desktop Server Configuration. 10
Slide 15: Manage RDS-CALs Wizard In Windows Server 2008 R2, a new wizard is available in Remote Desktop RD Licensing Manager that allows administrators to perform the following tasks:   Migrate RDS-CALs from one license server to another Rebuild the RD Licensing database Note The Manage RDS-CALs Wizard can only be used for a license server running Windows Server 2008 R2. Consider migrating RD CALs from one license server to another if one license server is being replaced with the other or if one license server is no longer functioning. By using the Manage RDS-CALs Wizard, administrators can automatically migrate RDS-CALs from one license server to another. If migrating RDSCALs from a license server that is not running Windows Server 2008 R2, manually remove the RDS-CALs from the original license server when the migration process is complete. Caution Rebuilding the RD Licensing database deletes any RDS-CALs currently installed on the license server. Those RDS CALs must be reinstalled on the license server after the database is rebuilt. Service Connection Point Registration When the RD Licensing role service in Windows Server 2008 R2 is added using Remote Desktop Server Manager, the license server attempts to register as an SCP in AD DS. When a license server is registered as an SCP, it appears in the list of known license servers in Remote Desktop Server Configuration. If AD DS is not available during installation of the RD Licensing role service, manually register the license server by using Review Configuration in Remote Desktop RD Licensing Manager. For information about other new features in RDS, see What's New in Remote Desktop Services at http://technet.microsoft.com/en-us/library/dd560658.aspx. Support for Virtual Desktop Infrastructure (VDI) One of the key new features of RDS is the ability to provide users with a VM-based remote desktop, or virtual desktop. Virtual desktops run client operating systems hosted on Hyper-V–based servers located in a data center. With RDS and VDI, users can experience rich and individualized desktops with full administrative control over the desktop and the applications. Administrators have the ability to configure dedicated personal desktops that will provide a consistent desktop experience for users that is similar to the experience of using a dedicated desktop or portable computer. Alternatively, VDI desktops can be pooled and dedicated to a specific set of applications. Key components of a virtual desktop infrastructure with RDS include the RD Virtualization Host and Hyper-V. RD Virtualization Host The RD Virtualization Host feature is an RDS role service included with Windows Server 2008 R2 that integrates with Hyper-V to provide VM-based remote desktops leveraging RemoteApp and Desktop Connections and RD Web Access to publish these resources to users. User accounts can be assigned a 11
Slide 16: unique personal virtual desktop or redirected to a shared VM pool in which a virtual desktop is dynamically assigned. If a user is assigned and requests a personal virtual desktop, RD Connection Broker redirects the user to this VM. If the VM is not turned on, RD Virtualization Host turns on the VM, and then connects the user. If the user is connecting to a shared VM pool, RD Connection Broker first checks to see whether the user has a disconnected VM session in the pool. If the user has a disconnected session, the user is reconnected to that VM. If the user does not have a disconnected session, a VM in that pool (if one is available) is dynamically assigned to the user. Hyper-V Hyper-V provides the virtualization management and host platform for the virtualized client operating systems. It has also been enhanced in Windows Server 2008 R2, providing support for live migration of VMs. There is no perceived downtime in the desktop workloads running in the VM, and network connections from and to the VM being migrated stay connected. This capability is possible between hosts within a high-availability cluster. Other improvements that Hyper-V provides include:  Dynamic VM storage. Improvements to VM storage include support for hot plug-in and hot removal of the storage. By supporting the addition or removal of virtual hard disks and physical disks while a VM is running, it is possible to quickly reconfigure VMs to meet changing requirements. Administrators can also add and remove both virtual hard disks and physical disks to existing SCSI controllers of VMs. Hot plug-in and removal of storage requires the installation of Hyper-V integration services (included in Windows Server 2008 R2) on the guest operating system. Enhanced processor support. Now, up to 32 physical processor cores are available. The increased processor support makes it possible to run even more demanding workloads on a single host. In addition, there is support for Second-Level Address Translation (SLAT) and CPU Core Parking. CPU Core Parking enables Windows and Hyper-V to consolidate processing onto the fewest possible number of processor cores and suspends inactive processor cores. SLAT adds a second level of paging below the architectural x86/x64 paging tables in x86/x64 processors. It provides an indirection layer from VM memory access to the physical memory access. In virtualization scenarios, hardware-based SLAT support improves performance. With Intel processors, this feature is called Extended Page Tables (EPT); with AMD processors, it is called Nested Page Tables (NPT).  Microsoft System Center Virtual Machine Manager 2008 R2 (in beta as of this writing). System Center Virtual Machine Manager simplifies the deployment, provisioning, and management of the virtualized desktop running in VMs. Although not required, it is strongly recommended to minimize the administrative overhead of managing production virtual servers. For additional information on Hyper-V in Windows Server 2008 R2, see What’s New in Hyper-V at http://technet.microsoft.com/en-us/library/dd446676.aspx.  12
Slide 17: Full-Fidelity User Experience The new capabilities mentioned so far, enabled with Windows Server 2008 R2 in combination with Windows 7 Enterprise and Windows 7 Ultimate, significantly improve the experience of remote users, making it more similar to the experience enjoyed by users accessing local computing resources. These improvements include:  Multimedia redirection. Provides high-quality multimedia by redirecting multimedia files and streams so that audio and video content is sent in its original format from the server to the client and rendered using the client’s local media playback capabilities. True multiple-monitor support. Enables support for up to 16 monitors of almost any size, resolution, or layout with RemoteApp and Remote Desktop; applications will behave just like they do when running locally. Audio input and recording. Supports any microphone connected to the user’s local machine, enables audio recording support for Voice over IP (VoIP) scenarios, and enables applications such as speech recognition for RDS clients. Windows Aero Glass support. Provides users with the ability to use the Windows Aero Glass experience for RDSH Servers, ensuring that Remote Desktop sessions look and feel like local desktop sessions. Enhanced bitmap acceleration. Allows rich media content, such as portable graphics stacks (Silverlight, Flash) and 3D content, including applications using DirectX versions 9, 10, and 11, to be rendered on the host and to be sent as accelerated bitmaps to the remote client. Improved audio/video synchronization. RDP improvements in Windows Server 2008 R2 are designed to provide closer synchronization of audio and video content in most scenarios. Language bar redirection. Allows users to easily and seamlessly control the language setting (for example, right to left) for RemoteApp programs using the local language bar.       Remote Application Access The new RemoteApp and Desktop Connection feature provides a set of resources, such as RemoteApp programs and remote desktops. These feeds are presented to Windows 7 users using the new RemoteApp and Desktop Connection Control Panel item. RemoteApp and RD Web Access provide the ability to connect to resources from the Windows Vista® and Windows XP operating systems in addition to Windows 7. Using the RemoteApp and Desktop Connections Control Panel item, a user can easily connect to RemoteApp programs and remote desktops. RemoteApp programs and desktops show up in the Start menu, and a new system tray icon shows connectivity status to all the connections the user has. 13
Slide 18: New Management Features There have been a number of management-related improvements for RDS in Windows Server 2008 R2, including:   New APIs for greater software leverage and awareness. Tighter integration between RDS management and Remote Desktop Server Manager, which reduces the number of Microsoft Management Console (MMC) windows required to perform common administrative tasks, reducing administrative complexity and effort. Features like Connected Broker Extensibility and Windows PowerShell support further enhance the flexibility that administrators have in designing an RDS/VDI infrastructure. Windows PowerShell cmdlets provide the ability to fully manage RDS, augment the graphical management tools, and help automate repetitive management tasks. A Best Practice Analyzer gives administrators instant validation and feedback for new RDS installations.   Roaming User Profile Cache Management An RDS environment can potentially have hundreds of distinct users. Whereas caching of roaming user profiles is enabled for a better user experience, this profile cache can grow very large and may potentially overrun the available disk space on the server. Controlling the cache size of individual user profiles may not be effective on the RDSH Server, because there can be hundreds of new, distinct users. A new Group Policy setting is available for RDS in Windows Server 2008 R2 that limits the size of the overall roaming profile cache (located in %systemdrive%\users directory). If the size of the profile cache exceeds the configured size, RDS deletes the least recently used copies of roaming profiles until the overall cache goes below the quota. Administrators can configure the maximum size of the roaming user profile cache on a RDSH Server by using Group Policy. The policy setting is found in the following location: Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Profiles\Limit the size of the entire roaming user profile cache. To enable this policy setting, specify a monitoring interval (in minutes) and a maximum size (in gigabytes) for the entire roaming user profile cache. The monitoring interval determines how often the size of the roaming user profile cache is checked. Fair Share CPU Scheduling Fair Share CPU Scheduling dynamically distributes processor time across sessions based on the number of active sessions and the load on those sessions. This is done by using a new kernel-level scheduling mechanism included with Windows Server 2008 R2 that will respond significantly faster than Windows System Resource Manager (WSRM) did in Windows Server 2008. On an RDSH Server, one user will not affect the performance of another user’s session, even if the RDSH Server is under a high load. 14
Slide 19: Fair Share CPU Scheduling is enabled by default. To disable this feature, configure the following Group Policy item: Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Server\Profiles. Note: as of this writing the Group policy Configuration has a known issue. This setting can also be disabled by setting the following registry entry to 0: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SessionManager\DFSS\EnableDFSS Prior to Windows Server 2008 R2, the Windows Scheduler provided a fair scheduling policy by distributing the processor time evenly across all threads at a given priority level. Priority could be adjusted by using management software such as WSRM to give one thread preference over another. In an environment with multiple users, this scheduling policy provided a good way to throttle any one user from completely monopolizing the processor but was unable to evenly distribute the processor time in the presence of dynamic loads. WSRM can still be used to provide more granular control of the new scheduling mechanism in Windows Server 2008 R2. 15
Slide 20: Application Compatibility RDS includes several new application-compatibility updates to make installing, managing, and providing access to applications easier. Windows Installer (MSI) application issues have been alleviated by enhancements to the Windows Installer. Most applications were written to be installed on the desktop and often required special steps for installation on a terminal server machine. Windows Installer adds missing per-user configuration settings during the initial application startup phase to reduce the need to install applications using special installation modes. If a user is permitted to install applications, RDS can allow concurrent MSI installations from multiple users. It accomplishes this by queuing installation requests and processing them sequentially. Remote Desktop IP Virtualization Previously, when applications were required to comply with specific IP address connection rules, Terminal Services could experience issues providing remote users access to applications. These rules may be the result of regulatory or security policies. Remote Desktop IP Virtualization allows IP addresses to be assigned to Remote Desktop sessions on a per-user or per-program basis. Some programs require that each instance of the application be assigned a unique IP address. Prior to Windows Server 2008 R2, every session on an RDSH Server was assigned the same IP address. With Windows Server 2008 R2, the administrator can specify a network ID that Remote Desktop IP Virtualization uses to assign IP addresses on a per-user or per-program basis. IP addresses are dynamically assigned to applications through the Dynamic Host Configuration Protocol (DHCP). Once a user has launched an application and initiated a session that requires a virtual IP address each subsequent user that uses the application will use the IP address that was acquired by the first user. Any application that is not configured to run with a virtual IP address will continue to us the RDSH server’s address. These settings can be configured in the Server Manager MMC or by group policy. Windows Installer RDS Compatibility Prior to RDS in Windows Server 2008 R2, only one Windows Installer installation was supported at a time. As a result, if multiple users logged on and invoked an installation (or first run of an MSI application), then the two users would conflict, meaning that one would continue to run but the other would see an issue (for example, two new users logging on to a terminal server at the same and starting Office Word). Windows Installer RDS Compatibility is a new feature included with RDS in Windows Server 2008 R2 in which per-user application installations are queued by the RDSH Server, and then handled by Windows Installer, ensuring that the user does not see an error message. Enhancements to the RDS installer also allow administrators to install applications without the need to user the setup/install mode. When installing application it is important to install for all users, and ensure that all components required are installed locally. 16
Slide 21: Windows Installer RDS Compatibility is enabled by default. To disable this feature, configure the following registry key to 0: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Terminal Services\TSAppSrv\TSMSI\Enable. 17
Slide 22: At-a-Glance Feature Comparison by Version RDS in Windows Server 2008 R2 offers many new features and functionality over previous versions. The key features are highlighted in Table 3. Table 3. RDS–Terminal Services Feature Comparison RDS in Windows Server 2008 R2 Key features RDSH Server RemoteApp RD Gateway RD Web Access RD Easy Print 4 Terminal Services in Windows Server 2008 Terminal Services in Windows Server 2003 Requires Windows Vista with Service Pack 1 (SP1) or Windows XP with SP3 RDC X X X X X X X X X X X X X X X X X X X Unified Remote Desktop and Web client RDVH Server Experience features 24-bit color 32-bit color Font smoothing Display data prioritization Large resolution support (4096 × 2048) Monitor spanning Multiple monitors Advanced compression Windows Aero Glass Windows Media Remoting Device redirection Remote Desktop legacy printer redirection Plug-and-Play device redirection framework support Serial port redirection Sound redirection Basic clipboard redirection 1 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X 18
Slide 23: RDS in Windows Server 2008 R2 Advanced clipboard redirection Security Smart card support Federal Information Processing (FIPS) 140-1 support Secure Sockets Layer (SSL) authentication Network-level authentication CredSSP single sign-on (SSO) 5 Terminal Services in Windows Server 2008 X Terminal Services in Windows Server 2003 Requires Windows Vista with Service Pack 1 (SP1) or Windows XP with SP3 RDC X X X X X X X X X 3 X X X X X X X X X X X X X X X X Network Access Protection (NAP) 2 integration RDP signing Wildcard SSL certificate support Enterprise management Per-user license tracking Per-device license tracking and enforcement License diagnosis and support tools RD Connection Broker (session-based load balancing) Session directory (non-Microsoft Network Load Balancing [NLB] support) WSRM support Full IP version 6 (IPv6) support Windows PowerShell integration Performance Fairly distributes processor cycles across sessions Sharing on a per-CPU basis X X X X X X X X X X X X X X X X X X X X X 19
Slide 24: RDS Scenarios RDS can be useful in a many scenarios. Typically, there are two main drivers for scenarios that users need. Some common scenarios that benefit from RDS are user-based scenarios and administrator-based scenarios. Many additional scenarios could benefit from RDS, but those mentioned here are meant as a general overview of the more popular scenarios. User Scenarios User-based scenarios are driven by a specific class of user. Common user types that benefit from RDS are mobile workers, task workers (such as factory floor and call center workers), contractor/offshore workers, and remote workers in branch offices. Mobile Workers If an organization needs to support employees who are mobile, work from home, or work from the road, a RDS solution can enable employee productivity anywhere and increase effective user collaboration without compromising security. RDS can offer secure access to desktops and applications over lowbandwidth connections without requiring new applications to be distributed to every client. Employees will see a consistent set of applications and can access their own data regardless of location. If employees need access to a comprehensive desktop experience, they can be assigned a personal virtual desktop within the confines of the corporate data center. This improves the RDS offering available to users while keeping the environment securely managed. With the wide adoption of third-generation (3G) wireless networks, users are even more capable of experiencing a full-fidelity desktop remotely. Task Workers If an organization includes structured task workers, such as in call centers and retail branches, RDS can provide a more cost-effective and productive user experience, because these user roles don’t typically need access to multiple applications to complete business processes. Additionally, there are situations when the location is simply not capable of supporting a fully functioning client computer; instead, thinclient solutions are more applicable. The same experience can be provided even if the client computer is a legacy computer, a non-Windows computer, or one of today’s mobile Internet devices (MIDs). This type of deployment can extend the reach of Windows-based applications within the enterprise and is a valuable way to deliver the right business tools in a cost-effective way. Contractor/Offshore Workers Many companies are leveraging workforce experience from around the world. Organizations will need to provide access to applications for users located both remotely and internationally. In order to provide access to resources while respecting corporate policies, providing a virtual desktop or virtual desktop pool becomes very attractive for organizations. This option allows users to receive a first-class client on the network while allowing the organization to control where the desktop is running, how the desktop is accessed, how data is being run on the client computer, and where data is stored. 20
Slide 25: Remote Workers: Branch Offices In an environment that relies on remote or branch offices, RDS can provide enhanced capabilities to these sites and reduce the network bandwidth that the required applications use. For example, a bank might have essential financial software applications that would not be cost-effective to deploy and maintain in every branch. With RDS, the software can be available at a central headquarters and accessed as needed by employees in different locations. A centralized-applications strategy often results in a reduction of application server infrastructure at various branches or locations, requiring much less maintenance and on-site support from the home office information technology (IT) staff. Administrator Scenarios Common administrator situations that benefit from RDS are regulatory compliance requirements, complex applications, and merger integration or outsourcing. Regulatory Compliance Requirements For the IT department, data security and the ability to meet regulatory requirements remains top of mind. RDS helps secure an application and its data in a central location, reducing the risk of accidental data loss caused by, for example, the loss of a portable computer. Key features of RDS such as RD Gateway and RemoteApp help ensure that partners or users who do not need full access to a company network or computers can be limited to a single application or desktop, if needed. Complex Applications In an environment with complex applications such as line-of-business (LOB) or customized legacy software, or in scenarios where large and complex applications are frequently updated but difficult to automate, RDS can greatly help simplify the process by reducing the burden of having to run multiple applications across the entire environment. Applications can be configured on a pool of virtual desktops that provide client machines access to the applications they require from a central source rather than requiring applications to be installed locally. Merger Integration or Outsourcing In the case of a merger, the affected organizations will typically need to use the same LOB applications, although they may be in a variety of configurations and versions. Additionally, organizations may find that they are working with outsourced or partner organizations that need access to specific LOB applications but not to the full corporate network. Rather than performing a costly deployment of the entire set of LOB applications across the extended infrastructure, these applications can be installed with the help of RDS on a Remote Desktop Server and made available to the employees and business partners who require access, when they need it. 21
Slide 26: Planning for Windows Server 2008 R2 RDS Planning and architecting Windows Server 2008 R2 RDS is a multistep process that should take into account users, applications, and availability requirements. If the organization intends on implementing virtual desktops, it also becomes necessary to plan infrastructure for Hyper-V, which means that if the organization had a Terminal Services infrastructure that had to comply with various high-availability requirements, IT will need to build a Hyper-v environment with the same specifications. Planning RDS includes considerations from a wide array of Windows services. The following sections cover the key considerations and provide an overview of different architectures for deploying RDS. Key Differences Between RDSH Servers and RDVH Servers Planning RDS architecture depends on the specific needs of the users that RDS infrastructure will be serving. It is important to target the correct technology for each scenario in which users may require remote access to a desktop or to applications. Table 4 illustrates several key differences between RDSH Server (formerly known as terminal servers) and RDVH Servers. Table 4. Key Differences Between RDSH Servers and RDVH Servers RDSH Server RDVH Server Comments Technology maturity Established Launched RDVH Server is a new component in Windows Server 2008 R2. It is important that stakeholders understand the new services and the associated implications, including users who are new to VDI concepts. It is also critical for management and corporate entities such as security teams and corporate policy enforcement teams to be aware of the impact that VDI will have on them. Scalability Higher ratio of Lower ratio of VMs require additional input/output (I/O) and memory. Policies can be users to servers users to servers put in place to insure that each VM receives a set amount of CPU time or memory usage; however, the number of users who will be accommodated on similar hardware will be lower when serving VMs. VM-based isolation VMs offer an additional level of administrative isolation. When users are directed to the virtual desktop, the supporting Hyper-V parent environment is completely abstracted from the user, which allows full Dedicated administrative lock-down of the hosting environment while allowing full operating system per user access to the VM. The VMs can even be placed on separate virtual local area networks (VLANs) for network isolation. Can run as administrator Protocoldependent Depending on the version of the RDP client, the user can experience a rich, high-fidelity desktop experience. Using RDC 7 and Windows 7, the client can take advantage of the visual enhancements of Windows Aero Glass, audio redirection, and high-definition video playback. Isolation/security Session-based isolation Shared operating system across users Must run as standard user Remote user experience Protocoldependent 22
Slide 27: RDSH Server RDVH Server Comments User flexibility User is running User can have as a user lowest full rights user privileges When users are connected to Remote Desktop sessions, they must be logged onto the Remote Desktop Server as a low privilege user to prevent the user from being able to make system-wide changes that may have impacts on other users. Using virtual desktops, users can be granted full rights to the desktop. Application compatibility Windows Server Windows client Many applications validate that they are running on a client operating operating desktop system. Often, applications will not run on a server operating system or systems in a Terminal Services session. Administrators now have the option to run these applications in a VM, where client version requirements can be met. Piloting RDVH Server Terminal Services has been a widely used technology in the enterprise for many years. Windows Server 2008 R2 introduces a solution to provide VDIs to users. Piloting the VDI solution requires planning not only traditional RDS technology using Remote Desktop session–based services but also considerations for Hyper-V infrastructure implementation. The following are key areas will need to be considered while planning a VDI deployment and should be determined during the testing and piloting steps. As this technology is being introduced with Windows Server 2008 R2, it will also be necessary to analyze the results of the trial on the following elements of VDI to determine the best course of action for your VDI deployment. Test or Pilot? Given budget and resource restraints, IT may wonder whether to test or to pilot. Unless the organization is prepared to spend large amounts of resources analyzing users’ work habits and capturing these actions into a simulated script, it is more effective to go into a pilot mode after having determined which RDS options are suitable for the organization’s users. The main goal of the pilot should be to demonstrate the benefits of deploying the technology. Sizing and Capacity Planning If the organization feels comfortable moving directly to a pilot phase and chosen a server configuration as a starting point, gradually add users to determine the maximum number that a system configuration (Terminal Server/network architecture/infrastructure servers) can support. To get a good understanding of the infrastructure scalability requirements, choose users from those across the different departments in the company that are typically a good fit for RDS—such as contractors or offshore workers in the case of VDI. Doing so provides a good understanding of the different usage pattern of these patterns for the different types of users and their acceptance for the solution. If the organization has chosen to employ a more formal planning process, Microsoft offers several tools that can help plan the required infrastructure for RDS:  Microsoft Assessment and Planning (MAP) Toolkit for Hyper-V. Helps administrators plan Hyper-V capacity requirements based on a comprehensive set of variables, including the 23
Slide 28: number of users, processor capacity, and network bandwidth. Go to http://technet.microsoft.com/en-us/solutionaccelerators/dd537570.aspx for details.  MAP Toolkit for Windows Server 2008. Plan the deployment of Windows Server 2008 computers and services. Go to http://technet.microsoft.com/enus/solutionaccelerators/dd537573.aspx for details. Microsoft System Center Capacity Planner 2007. Helps plan capacity for a management infrastructure that may be desired for the management and health of RDS. Go to http://www.microsoft.com/Systemcenter/en/us/capacity-planner.aspx for details. Regardless of the method used for planning and sizing RDS, It is important to implement a user feedback–collection process throughout the piloting and testing phases for the purpose of establishing policies and procedures to mitigate potential problems before they affect a large number of users. This feedback should also include input from the IT teams rolling out and supporting the RDS infrastructure. Finally, project stakeholders and management require a way to measure the feedback and how the pilot team is responding to the feedback. Addressing user issues and keeping stakeholders apprised of the status of the pilot are key to successfully moving to a full production rollout. RDVH Server Virtual Management and Storage Considerations The RDVH Server leverages the Hyper-V VM environment, which means that along with sizing server capacity to handle concurrent VMs, planning how to store virtual hard disk (VHD) images must be undertaken. Two types of virtual desktops should be considered, and both VDI scenarios have different storage implications: Personal VMs will have a dedicated VHD files, whereas VM pools may be able to share base VHD files. In the latter case, VHD state is not maintained over the life of the VM but rather over the life of the desktop session. VHD behavior depends on the VDI scenario:  Personal virtual desktops. Most users assigned a personal VM will have a single VHD dedicated to their virtual desktop. This VHD will change according to the user action on the VM. The state of the VM from one user login session to the next will remain the same. When planning storage requirements, there are considerations for which type of VHD to use—dynamically expanding or fixed—where the VHD will be stored, and whether local storage or a Storage Area Network (SAN) will be used. Figure 5 shows this scenario.  24
Slide 29: Figure 5. The personal virtual desktop scenario  Pooled virtual desktops. When pooled virtual desktops are implemented, the user’s environment remains the same across each VM in the pool. VHDs can be shared between users. User state and changes made during the Remote Desktop session is deleted from the VHD when the user logs off from the VM. However, roaming profiles and folder redirection can be used to provide additional flexibility to a virtual desktop pool setup. Planning VHD storage will center on understanding how much space the temporary user state across all VMs in the pool could take at if all VMs are being used at the same time. Figure 6 shows this scenario. Figure 6. The pooled virtual desktop scenario Personal and pooled virtual desktops address a diverse set of needs. Planning VHD storage for the pilot and rollout of virtual desktops will be a key step in a successful VDI deployment. Several key questions that should be answered are:  What percentage of the VDI user population will use each scenario? Answering this question requires an understanding of the applications that will be deployed, the level of administrative 25
Slide 30: access that users require, the need for user state to be saved on the VM, and the need for user state to persist from one session to the next. By answering this question, IT can plan the appropriate storage requirements for users of each scenario.  What type of users will use each scenario? The technical knowledge level of the users may affect the kind of virtual desktop deployed. It is important, however, to keep in mind that a strong business reason should be the foundation of any method, as both scenarios offer the possibility of a high level of administrative control. In the case of pooled VMs, how do you plan to handle user state? When a user logs on to a pooled VM, that user’s user state is created on the VM. If roaming profiles are in use in the environment, this means that each time a user logs on to a pooled VM, the user state is loaded and, when the user logs off, the user state is deleted. If users have a large user profile, this behavior may cause unacceptable delays when users log on.  In the case of pooled VMs, how often do you expect to refresh the pool with new images? Every time a VM is refreshed in a pool, all VMs in that pool must be refreshed. When planning the storage requirements, understanding the storage impact of refreshing pools of VMs prevents situations in which pools cannot be refreshed without affecting users. Each of these considerations helps determine what kind and how much storage will be most appropriate for the organization. Regardless of which scenario will be implemented, when planning the pilot phase, it is critical to base the initial architecture on a scalable storage mechanism. Doing so ensures a smooth transition from pilot to production as additional storage is required.  User Applications Another key area when planning for virtual desktops is to determine how users’ applications will be deployed to desktops. As traditional desktop applications require patching and updates, by leveraging the centralized nature of virtual desktops, patching can be performed directly on the VM in the data center. The ability to quickly deliver updates is increased, and the impact to users is minimized. When patching an application in a VM pool, all VMs must be patched. This requirement poses a challenge when the pool contains a significant number of VMs. When applications are deployed to a large number of personal desktops, it may be difficult to determine whether applications have been patched. Users with administrative control of the desktop may avoid patching, or desktops that have not been logged on to in a long time may be significantly out of date. To address these issues, it is recommended that where possible, application virtualization should be used to provide virtualized applications to virtual desktops. App-V abstracts the application life cycle from the user operating system. Applications are not physically installed on the computer, which means that application files, registry entries, COM objects, and services are not merged with a computer’s file system registry. Applications can be managed and deployed using MSI packages, making them deployable through many off-the-shelf electronic softwaredistribution systems, or they can be deployed using Microsoft System Center Configuration Manager 2007. System Center Configuration Manager also offers the option of streaming the applications to the target VMs, which minimizes the initial footprint of the application with minimal impact on users when they launch the application. 26
Slide 31: App-V also provides a solution for application-to-application compatibility issues, meaning that because applications run in isolated environments, they are not aware of the existence of other applications. As an example, this can allow different versions of Microsoft Office Access® to run on the same computer. This is also application-to-session–based application deployment, where App-V for Terminal Services can provides the ability to consolidate applications to a single RDSH Server. Using RemoteApp, administrators can also solve application-to-application compatibility issues by redirecting where the application is executed, again abstracting the application from the desktop environment. Considerations Consider deploying ubiquitous applications as part of the master image. Applications that are used as dependencies by many other applications, such as Microsoft Office applications, are good examples of the types of applications that would be included in the base image. Choosing which application abstraction technology to use could be based on how many applications need to be abstracted, how users will have applications deployed, and user requirements when using the applications. Consider using App-V’s ability to redirect user state to a network location (not into the profile). App-V can store user state information about virtual applications in a configurable location, which provides an option to allow user information to be in a network location, preserving a user’s application customizations even if using virtual desktops in a pool. Virtual Machine Preparation Preparing a VM for use in VDI requires preparing an image, or VM template. In large-scale deployments, this invariably requires deployment automation. Depending on the version of the virtual desktop operating system, this may require varying levels of deployment customization. Considerations VMs that are part of a VM pool need to be generalized to the point that no unique user information is part of the image. To accomplish this, when a VM is ready to be deployed into a VM pool, it needs to run the System Preparation Tool (Sysprep). Applying Sysprep to an operating system image removes unique information, such as the operating system’s globally unique identifier (GUID), and naming. When the VM is restarted, either it will prompt the user to enter information about the machine—asking for a name and domain information—or, as part of an automated deployment process, the VM would acquire this information itself. For additional details on automated deployment processes, refer to Microsoft Deployment Toolkit (MDT) 2010. Note Although other tools can generalize a Windows operating system image, only Sysprep is officially supported by Microsoft. 27
Slide 32: Patching Virtual Desktops Like any physical client computer, it is important to plan the patching of virtual desktops. Unlike physical desktops, patching VMs can be accomplished with a higher degree of certainty and can be performed faster. As patching is a crucial aspect of a healthy desktop life cycle, the patching strategy for virtual desktops should be planned from the testing phase in a VDI rollout. Using an automated patching service such as Windows Server Update Services (WSUS) is highly recommended. This server should be physically close to the VMs or linked using a high-speed connection. This ensures that VMs are patched as quickly as possible and minimizes downtime. Patching a VM can have an impact on the base VHD file over time. As administrators apply patches, the VHD image grows. In pooled environments, the amount of patching required—both for operating system and applications—should be estimated to get an idea of the growth of the hard disk. In some instances, it may be more desirable to recreate master images so that all VHDs deployed going forward are up to date. Using App-V, IT can separate application patching and operating system and core application patching into two separate and independent processes. Applications are deployed and sequenced separately from the base operating system. Microsoft recommends using this method, as it allows a more granular segmentation of maintaining applications and VMs. This in turn provides greater flexibility to assign maintenance of various applications and/or the operating system to different individuals or teams. User State One of the most volatile elements of managing VM-based desktops is handling user state. In both personal desktops and virtual desktop pools, user state must be handled in such way as to minimize the impact loading and managing user state have on the virtual desktop. User state can cause significant growth of VM images. To keep this growth controlled, several Windows user state–management features are available:   Use roaming profiles or mandatory profiles in conjunction with a strong user profile policy to keep user profile data to a controlled and predictable growth rate. Use Folder Redirection to keep folders that traditionally become large (such as the Documents folder or the Pictures folder) to a network location to keep the files from being stored as part of the VHD. Do not place Offline Folder (OST) and Personal Folder (PST) files in redirected folders. Because of the constant access nature of these file types, placing them on a network connection could cause a significant increase in avoidable network traffic. Implement quota policies to prevent users from surpassing expected usage. The importance of this step cannot be understated. It is important to find the right balance between user expectations and business needs, but users should understand that once the balance has been established, proper business-driven justification should be provided before the quotas policy is changed.   28
Slide 33: To keep the performance of the VMs as fast as possible, make sure that the servers hosting the user profile data are connected over a fast network connection to the VMs. Note Although many circumstances can limit the use of options such as roaming profiles with physical desktops, being able to place the profiles server next to the virtual host server alleviates the most common cause for not implementing roaming profiles. Network Designing the network environment for RDS includes the added dimension of planning for network communications with the virtual desktop as well as the communications between users and the RDSH Servers or RDVH Servers. Understanding the network environment is especially important when designing an RDS solution that involves wide area network (WAN) communications. Even infrequent network slowdowns can cause unacceptable performance to Remote Desktop Server users. Both latency (the time it takes a packet to reach the other end of the network) and bandwidth (the amount of data that can travel over the network within a given period of time) are important factors. Because everything users see on their screen is generated by the RDSH Server or RDVH Server, high latency has a serious impact on the perceived response of the system, while low bandwidth affects the time it takes to get large chunks of data (like bitmaps) to a user’s screen. Therefore, variables such as the typing rate of the users, the amount of graphics used in an application, and how many users are working at any one time over a WAN connection all factor into the equation when asking, “How many users can I connect to an RDS infrastructure a Remote Desktop Server over this type of connection?” The only reliable way of answering this question is to test it in an actual network. Keep in mind that the user experience very much depends on there being sufficient bandwidth available when the application is writing large amounts of information to the screen. Connecting over a low-bandwidth connection has no significant impact on RDSH Server/RDVH Server scaling. A low-bandwidth connection consumes just as many back-end resources as a high-bandwidth connection. Note With the introduction of high-definition (HD) video support, enhanced bitmap acceleration and Windows Aero, some features may not be available or performing well when accessing an RDSH Server/RDVH Server through a low-bandwidth connection. To maximize performance of the virtual desktops, the network required to move user state information should be sized to accommodate the use of roaming profiles or redirected folders. It is important to remember that the profile information should be placed on the same network or on fast link with the RDVH Server. This means ensuring that the physical server hosting the parent and child VMs has the required bandwidth not only to provide fast access between virtual desktops and profile data but Remote Desktop connections to the VMs. 29
Slide 34: The same goes for application access—especially when virtual applications are being used. If applications are being streamed, additional network capacity may be required to ensure expedient delivery of applications. Network consideration should also be taken into account when planning Remote Desktop VMs in conjunction with a network-based SAN. Appropriate network adapters should be dedicated for SAN communications. 30
Slide 35: Better Together: App-V and RDS Server growth is a costly issue for organizations that rely on RDS. To avoid post-installation application conflicts, applications must be tested up front to determine which applications may collide and, therefore, must be separated and run on different RDSH Server silos—a time-consuming and costly process. Servers are routinely underutilized, because each one is locked into a specific configuration, capable of serving only a limited set of non-conflicting applications and typically using just 25 percent of its capacity. With the introduction of RDVH Servers, entire desktops can be run on VMs. To maintain applications and provide them on VMs, VMs need to be taken offline for maintenance and testing needs to be performed to make sure the updated application do not conflict with already-installed software. Regression testing is all the more important with VM pools, as a software problem that goes undetected can affect every user accessing the pool. App-V completely changes this situation. App-V for RDS completely changes this situation. App-V for RDS: Features and Benefits App-V for RDS has many features and benefits that can add value to an organization:  Consolidate servers and end server siloing, increasing server farm return on investment (ROI). App-V for RDS allows any application to run alongside any other—even applications that typically conflict, multiple versions of the same application, and many applications that previously could not run under a session –based (i.e. Terminal Services) scenario. This eliminates the need for server silos and significantly improves server utilization. As a result, the number of servers needed is much lower, operational costs for managing the remaining servers is reduced, and the server farm ROI is increased. Often, customers can see up to a 40 percent reduction in the number of terminal servers needed by using App-V for RDS. End application conflicts and regression testing. By eliminating the need to permanently install applications on servers and shielding the operating system and applications from changes created when installed applications run, App-V for RDS prevents problems that hinder deployments. The need to perform lengthy regression testing is also significantly reduced. Deploy applications to RDSH Server users using RDS or RDVH Servers directly to virtual desktops with no interruption to users or servers. Typically, when new applications are installed on an RDSH Server, all users must be logged off, and often, the server must be restarted. Now, with virtualization of applications, it is possible to deploy the application to the server without a restart and without affecting the system or the users currently logged on. This makes deploying and maintaining applications a much lower-risk proposition and ensures that servers need less scheduled downtime while improving business agility. Build business continuity for applications. IT can replicate virtualized applications like any other enterprise data to maintain an instant on-failover plan for applications. Applications can be kept up to date between live sites and back-up sites by automatically replicating virtualized application files on the live sites’ servers to servers at a back-up site (using non-Microsoft tools).    31
Slide 36:  Simplify operating system migrations and patching. Turn time-consuming migration and patching projects into largely automated, conflict-free processes. Applications typically do not have to be repackaged for operating system migrations. Patching and migrations do not require regression testing. Scalability. The unique approach of App-V for RDA enables applications to be centrally stored, and then delivered and executed on RDSH Servers on demand. Application files are only delivered once to the RDSH Server, where they are cached for repeat use by multiple users. As a result, App-V for RDS is a bandwidth-efficient method of distributing applications to RDSH Servers, ensuring that many RDSH Servers and thousands of connected users are supported. Integration with System Center Configuration Manager. With System Center Configuration Manager, administrators get the benefits of application virtualization and dynamic streaming from within the System Center Configuration Manager infrastructure. This provides the flexibility to choose the best way to deploy and run applications while maintaining operating system–level patches, updates, inventory, and asset tracking with a single, integrated management point.   32
Slide 37: Summary Windows Server 2008 R2 RDS provides a flexible set of options for administrators to deploy applications and support users. With the introduction of virtual desktops, administrators can provide isolated fullfidelity desktop environments that can be first-class citizens in the corporate environments. Administrators maintain management, control, and security over desktops and can enforce corporate policies and industry regulations. 33