Windows Server 2008

Presentation Virtualization with Enhanced Terminal Services

Joshua Schnoll

At a Glance:

• New features in Windows Server 2008 Terminal Services
• Using TS Gateway for remote access
• Load-balancing with TS Session Broker

Contents

What's New in Terminal Services
Security Features
User Experience Features
Easier Remote Access
Terminal Services Gateway
TS Session Broker

Virtualization is a hot term these days, though most of the time people think it relates only to virtual machines and the virtualization of operating systems. However, Terminal Services has been abstracting the presentation layer of remotely run applications and desktops since the release of Windows NT 4.0. Terminal Services has come a long way since that time, and Windows Server 2008 delivers a mature, robust presentation virtualization platform. I will focus the key areas of improvement in Terminal Services.

What's New in Terminal Services

Terminal Services in Windows Server 2008 has many new features and capabilities:

Terminal Services RemoteApp One of the great changes in Windows Server 2008 is the ability to remote a single application. In previous versions of Terminal Services, the entire remote desktop was transmitted, even if you only wanted to access a single application. This was often confusing to users because some applications appeared on the remote desktop (via Terminal Services) and some on the local desktop—and remembering which desktop had which application could be challenging. Now, applications accessed through Terminal Services look and behave as if they were running on the end user's local computer.

Terminal Services Web Access High on everyone's wish list was a simple way for end users to launch applications. TS Web Access meets that need by allowing administrators to publish individual applications to a Web page. TS Web Access includes a default Web page that can be deployed right out of the box, but it also can be customized and integrated into a SharePoint site. In order to launch a TS RemoteApp with TS Web Access, the user visits a Web page (accessed either from the Internet or intranet), sees a list of all the available applications, and clicks on the one he wants to launch.

In Windows Server 2003, a separate ActiveX control called the Remote Desktop Web Connection (RDWC) was required to enable a connection from a browser. Now the control has been built right into the main Remote Desktop Connection (RDC) client, so nothing needs to be downloaded or installed to the client. Moreover, the full Remote Desktop Protocol (RDP) feature set is supported, which wasn't the case with the old RDWC client.

Terminal Services Gateway TS Gateway is one of the most significant new features in Windows Server 2008. RDP traffic runs over port 3389, and one of the major issues administrators had when deploying a terminal server to users outside the firewall was having to either open that port in the firewall (not recommended) or use a separate VPN solution (costly). With TS Gateway, the RDP traffic is tunneled over HTTPS (port 443) to establish an encrypted connection between remote users on the Internet and the terminal server (or remote PC). Even better, the scenario works great even if the user or terminal server is located behind a network address translation (NAT) traversal-based router.

TS Gateway can be coupled with another feature of Windows Server 2008, Network Access Protection (NAP), to help ensure the health of client machines before granting access to Terminal Services resources.

Terminal Services Session Broker Windows Server 2000 introduced Network Load Balancing (NLB) and, though it works really well for Web servers, it wasn't ideal for load balancing Terminal Services. The new TS Session Broker provides a great alternative by expanding the Session Directory capabilities of Windows Server 2003 to enable session-based load balancing.

With TS Session Broker, new sessions are distributed to the least-loaded server within the farm and users don't have to know where a session was established in order to reconnect to an existing session. IT managers can use the feature to map the IP address of each Terminal Server to a single DNS entry. This configuration can also provide fault tolerance; if one of the farm servers is unavailable, users will connect to the next least-loaded server in the farm.

Terminal Services Easy Print Printing has historically been the bane of many an administrator's existence in a Terminal Services environment. With matching print drivers required on both server and client machines, end users had less flexibility to install printers while administrators had to worry about managing print drivers on the server. With TS Easy Print, in contrast, users can now reliably print from TS RemoteApp or a full desktop session to a local print device, whether it is attached directly or via a network. The best part is that printers can now be supported without it being necessary to install drivers on the terminal server.

When a user wants to print from a TS RemoteApp program or desktop session, he will see the full printer properties dialog box from the local client and have access to all the printer functionality (such as watermarks, collating, and stapling). When the user prints, the print job is rendered with the Microsoft XPS file format on the server and sent to the client. Furthermore, with TS Easy Print, administrators can use Group Policy to limit the number of printers redirected to just the default printer, thereby reducing overhead and improving scalability.

Those are the "big ticket" features in Windows Server 2008. We will revisit TS RemoteApp, TS Web Access, TS Gateway, and TS Session Broker later in this article. First, let's take a look at some other great but less prominent features in this release.

Security Features

Security has been beefed up in the new release of Terminal Services.

Network Level Authentication (NLA) and Server Authentication (SA) With previous versions of TS, a denial-of-service or man-in-the-middle attack could have been launched against the logon screen of the terminal server, as users were presented with the logon screen after clicking Connect on the RDC client. Now NLA authenticates the user, client machine, and server credentials against each other before a TS session is spun up on the server and the logon screen is presented to the user. Server Authentication uses Transport Layer Security (TLS) to help ensure that clients are connecting to a legitimate terminal server and not some rogue machine.

Single Sign-On Users want to be able to use one set of credentials (a user-password combination or a smart card and PIN combination) to authenticate just once, and not to be asked over and over for those credentials each time they want to use a new resource. With this release, domain-joined machines running Windows Vista or Windows Server 2008, connecting to a Windows Server 2008-based terminal server or TS Gateway, can now utilize single sign-on.

System-Level Hardening Both Windows Vista and Windows Server 2008 have new system-level hardening, which basically modularizes components of the operating system and runs them at lower privilege levels. In Terminal Services, this feature was implemented by splitting the core TS engine (termsrv.dll) into two separate components (lsm.exe, the core session manager, and termsrv.dll for remote connectivity).

Previously, termsrv.dll ran at the higher system privilege level. Now, only one-third of the original termsrv.dll code runs at that level in the new lsm.exe; the remaining two-thirds run at the much lower network service privilege level. This change significantly reduces the attack surface compared to Windows Server 2003.

User Experience Features

A number of improvements help users:

Custom Display Resolutions With the expansive growth of large monitors and a wider variety of display resolution ratios, Windows Server 2008 Terminal Services steps up to meet your needs.

The end user has the ability to set custom display resolutions (up to 4096 x 2048) or change the ratios to 16:9 or 16:10 to get a wide­screen experience. All types of new monitor configurations can be supported, such as monitors with resolutions of 1680 x 1050 or 1920 x 1200. This is a great improvement over Windows Server 2003, which supported a maximum resolution of 1600 x 1200 and only 4:3 display resolutions ratios. You can set a custom display resolution from the RDC client dialog box, in an .rdp file, or from a command prompt.

In order to set a custom display resolution in an .rdp file, open the .rdp file in a text editor and add or change the following settings (note that <value> is the resolution, such as 1680 or 1050):

desktopwidth:i:<value>
desktopheight:i:<value>

To set a custom display resolution from a command prompt, use the mstsc.exe command with the following syntax (note that <width> and <height> are the resolution, such as 1680 or 1050):

mstsc.exe /w:<width> /h:<height>

Monitor Spanning Remote desktop sessions are now able to span multiple monitors. There are a few prerequisites for this feature to work properly:

• All monitors must use the same resolution. For example, two monitors using 1024 x 768 can be spanned. But one monitor at 1024 x 768 and one monitor at 800 x 600 cannot be spanned.
• All monitors must be aligned horizontally (that is, side-by-side). There is currently no support for spanning multiple monitors vertically on the client system.
• The total resolution across all monitors cannot exceed the maximum resolution of 4096 x 2048.

To enable monitor spanning in an .rdp file, open the .rdp file in a text editor and add or change the following settings (note: if <value>=0, monitor spanning is disabled, if <value>=1, it is enabled):

Span:i:<value>

To set monitor spanning from a command prompt, use the mstsc.exe command with the following syntax:

mstsc.exe /span

Desktop Experience Desktop Experience makes a Terminal Services desktop much more like the Windows Vista desktop experience. This feature adds a number of components to the remote desktop, including Windows Media Player 11, desktop themes, and photo management. Here's how to enable Desktop Experience:

1. Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.
2. Under the Features Summary, click Add Features.
3. On the Select Features page, select the Desktop Experience checkbox and then click Next.
4. On the Confirm Installation Selections page, verify that the Desktop Experience feature will be installed and click Install.
5. On the Installation Results page, you are prompted to restart the server to finish the installation process. Click Close, and then click Yes to restart the server.

Once the server has restarted, you must then confirm that the Desktop Experience feature is installed.

Font Smoothing Font smoothing is the name for Terminal Services support for ClearType, which helps display computer fonts more crisply, especially on an LCD monitor. Font smoothing is enabled by default in Windows Server 2008, and it can be enabled when a client computer connects through a checkbox in the Remote Desktop Connection, as shown in Figure 1.

Figure 1 Enabling font smoothing

You should note that font smoothing increases the bandwidth (from 4 to 10 times, depending on the scenario) used between the client computer and the terminal server. This increase in bandwidth occurs because ClearType fonts are remoted as bitmaps instead of glyphs, which RDP handles much more efficiently.

Display Data Prioritization With Windows Server 2003, printing a large job could often make your on-screen experience suffer. Display data prioritization automatically controls virtual channel traffic so that display, keyboard, and mouse data is given a higher priority over other traffic, such as printing or file transfers. This prioritization is designed in order to ensure that your screen, keyboard, and mouse performance is not impacted by bandwidth-intensive actions, such as large print jobs.

Out of the box, the setting is 70:30. Display and input data are allocated 70% of the bandwidth while all other traffic, such as file transfers or print jobs, will be allocated 30%.

You can adjust the settings by making changes to the registry of the terminal server. To do so, change the value of the following entries under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser­vices\Term­DD subkey:

FlowControlDisable
FlowControlDisplayBandwidth
FlowControlChannelBandwidth
FlowControlChargePostCompression

If these entries do not appear, you can add them by right-clicking TermDD, point to New, and then click DWORD (32-bit) Value.

You can disable display data prioritization by setting the value of FlowControl­Disable=1. If display data prioritization is disabled, all requests are handled on a first-in-first-out basis. The default value for FlowControlDisable=0.

You can set the relative bandwidth priority for display (and input data) by setting the FlowControlDisplayBandwidth value. The default value is 70; the maximum value allowed is 255. Likewise, you can set the relative bandwidth priority for other virtual channels (such as clipboard, file transfers, or print jobs) by setting the FlowControlChannelBandwidth value. The default value is 30; the maximum value allowed is 255.

The bandwidth ratio for display data prioritization is based on the values of FlowControlDisplayBandwidth and FlowControlChannelBandwidth. For example, if FlowControlDisplayBandwidth is set to 150 and FlowControlChannelBandwidth is set to 50, the ratio is 150:50. As a result of this, display and input data will be allocated 75% of the bandwidth.

The FlowControlChargePostCompression value determines if flow control will calculate the bandwidth allocation based on pre-or post-compression bytes. The default value is 0, which means that the calculation will be made on pre-compression bytes.

If you make any changes to the registry values, you need to restart the terminal server for the changes to take effect.

Plug and Play Device Redirection In Windows Server 2008 Terminal Services, device redirection has been enhanced and expanded. Now you can redirect Windows Portable Devices, specifically media players based on the Media Transfer Protocol (MTP) and digital cameras based on the Picture Transfer Protocol (PTP).

This functionality can be enabled with the Options button in the Remote Desktop Connection. When it's enabled, a list of supported Plug and Play devices that are currently plugged in will show up. Unsupported devices will not appear. You can also select the option to redirect devices that have not been plugged in yet. Figure 2 shows how to enable these from the RDC client.

Figure 2 Enabling devices that are not yet plugged in

When the session to the remote computer is launched, you should see the Plug and Play device that is redirected get automatically installed on the remote computer—Plug and Play notifications will appear in the taskbar. After the redirected Plug and Play device is installed, it is available for use in your session with the remote computer. For example, if you are redirecting a Windows Portable Device such as a digital camera, it can be accessed directly from an application such as the Scanner and Camera Wizard on the remote computer.

You can control Plug and Play device redirection by using either of the following Group Policy settings:

• Do not allow supported Plug and Play device redirection located in Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Device and Resource Redirection.
• The policy settings located in Computer Configuration\Administrative Templates\System\Device Installation\Device Installation Restrictions.

You can also control Plug and Play device redirection on the Client Settings tab in the Terminal Services Configuration tool (tsconfig.msc) by using the Supported Plug and Play Devices checkbox.

Easier Remote Access

I mentioned earlier that TS RemoteApp lets users remote a single application and TS Web Access lets them access applications easily from a Web page; now let's take look a little closer at these features and at some of the configuration details.

TS RemoteApp RemoteApp programs can be deployed to user desktops through a variety of methods. In addition to TS Web Access, you can also:

• Create a Remote Desktop Protocol file.
• Create a program icon on the desktop or Start menu via a previously distributed Windows Installer (.msi) package.
• Execute a file where the file name extension is associated with a RemoteApp program. This can be configured by the administrator with a Windows Installer package.

For more information on how users can access RemoteApp programs, see "How Should I Deploy RemoteApp Programs?" in the Windows Server 2008 TS Remote­App Step-by-Step Guide at go.microsoft.com/fwlink/?LinkID=84895.

TS Web Access TS Web Access enables the deployment of RemoteApp programs from a single server or a farm of terminal servers. The TS RemoteApp Manager provides a very quick and efficient process for publishing applications into TS Web Access—first you install Terminal Services, then you install the applications you want to host.

Use TS RemoteApp Manager to add Remote­App programs that are enabled for TS Web Access. Next, install TS Web Access on the server to which you want users to connect over the Web. Add the computer account of the TS Web Access server to the TS Web Access Computers group on the terminal server. Finally, configure the TS Web Access server to populate its list of RemoteApp programs from a single terminal server or single farm.

Once the applications have been installed through the traditional method or delivered to the terminal server with Application Virtualization (formerly known as SoftGrid), it is very straightforward to publish those applications to TS Web Access. The Remote­App Wizard walks the administrator through a few quick and easy steps and the applications then appear on the list of published Remote­App Programs.

By default, the applications will be published to TS Web Access. RemoteApp Manager will then show you a list of applications that have been published and all the applications that are available to users through TS Web Access.

Now let's take a quick peek at the out-of-the-box end user experience. The first tab in TS Web Access shows the icons of all the applications that are published (see Figure 3); the second tab lets users connect to a specific desktop computer using the Web front end. As noted earlier, this Web interface is completely customizable and the "TS Web Access Step-by-Step Guide: Customizing TS Web Access by Using Windows SharePoint Services," available at go.microsoft.com/fwlink/?LinkID=111241, is a great resource that walks you through a customization with SharePoint Services.

Figure 3 Entering settings for the .rdp files (Click the image for a larger view)

Other Deployment Methods Besides using TS Web Access, you can deploy RemoteApp programs with .rdp files or Windows Installer packages. Those packages can be distributed through file sharing, or through Microsoft Systems Center Operations Manager or Active Directory software distribution. The next section will walk you through the key steps to create the right packages for application distribution.

To prepare RemoteApp programs for distribution through a file share or some other distribution mechanism, you must install Terminal Services and the apps you want to publish, and verify remote connection settings. The TS RemoteApp Wizard will help you to add RemoteApp programs and configure global deployment settings. Then you can create .rdp files or Windows Installer packages.

Let's walk quickly through the Remote­App Wizard. In Step 1, you configure the Terminal Server, TS Gateway, and Certificate settings for the .rdp files (see Figure 4).

Figure 4 Setting options for the program package (Click the image for a larger view)

In Step 2, you specify where the shortcut icons will appear on the desktop or Start menu and/or associate client file extensions so that local files will launch with the Remote­App (see Figure 5).

Figure 5 Viewing RemoteApp programs in TS Web Access (Click the image for a larger view)

In the final step, the RemoteApp Wizard opens the Packaged Programs folder so you can easily deploy these packaged applications to client machines with the distribution software of your choice (see Figure 6).

Figure 6 Programs packaged for deployment (Click the image for a larger view)

Terminal Services Gateway

Now I am going to examine how TS Gateway can help your remote users get access to applications, data, or desktops from outside the firewall. Figure 7 shows at a very high level the typical scenario for deploying TS Gateway in order to provide access to users through the Internet.

Figure 7 Worker connecting from laptop at home to a corporate network (Click the image for a larger view)

In essence, the TS Gateway sits in the network perimeter and tunnels the RDP traffic over HTTPS. Alternatively, you could place an SSL terminator (such as Microsoft Internet Security and Acceleration Server—ISA) in the network perimeter and forward the incoming RDP traffic to your TS Gateway on the other side.

Here are the steps illustrated in Figure 7:

1. A user on a home laptop can connect via the Internet by clicking on either an RDP file or a RemoteApp program icon located on the desktop, on the icon of a TS RemoteApp published via TS Web Access, or by opening the Remote Desktop Connection client.
2. An SSL tunnel is established between the home laptop and the terminal servers using the TS Gateway server's SSL certificate. Before a connection is established, the user must be authenticated and authorized according to Terminal Services connection authorization policies (TS CAPs) and Terminal Services resource authorization policies (TS RAP). Once the TS RAP and TS CAP polices (discussed below) have been enforced, the user can open a session.
3. The home laptop exchanges encrypted RDP packets encapsulated within SSL with the TS Gateway over port 443. The TS Gateway forwards the RDP packets to terminal server over port 3389.

You can create a farm of TS Gateway servers for larger installations, but you will need a separate solution (such as NLB or a third-party load balancer) in order to balance the load among the server farm systems. TS Session Broker does not handle load balancing for TS Gateway server.

Now let's take a quick look at how to deploy this functionality. In a nutshell, you need to obtain and configure a certificate for the TS Gateway server and create the two types of authorization policies I mentioned earlier: TS CAP and TS RAP.

Obtaining a Certificate You can either use an existing certificate or request a new one. A valid certificate is required for the TS Gateway to function and you have a choice during installation to import a certificate or create a self-signed certificate.

The self-signed option is good if you are doing internal testing, but proper deployment requires a certificate issued by an enterprise certificate authority (such as VeriSign). Once you have the certificate installed, you can then consider your deployment authorization policies.

Authorization Policies TS CAPs determine who can connect to the TS Gateway and specify under what conditions users can connect. For example, you can specify that a user group that exists on the local TS Gateway server or in Active Directory can connect to a TS Gateway and that group members must use smart cards.

TS RAPs, on the other hand, determine which internal resources users can access via the TS Gateway. For example, you can create a computer group (such as a farm of terminal servers) and associate it with your TS RAP.

You need to create both TS CAPs and TS RAPs to give remote users access to internal resources, as a user must meet the conditions of at least one TS CAP and one TS RAP in order to have access. Administrators can create both types via the TS Gateway Manager, as shown in Figure 8 and Figure 9.

Figure 8 Creating a connection authorization policy (Click the image for a larger view)

Figure 9 Creating a resource authorization policy (Click the image for a larger view)

Together, TS CAPs and TS RAPs provide two different types of authorization that allow you to configure a more finely tuned level of access control to computers on an internal network. For more information, see the "Terminal Services Gateway Step-by-Step Guide" at go.microsoft.com/fwlink/?LinkID=85872.

TS Session Broker

The last topic I'd like to cover is Session Broker, which provides a simple-to-deploy, session-based, load-balancing solution. The functionality builds on the Session Directory capabilities of Windows Server 2003 that reconnected a user to an existing session, and adds it the ability to create a new session on the least-loaded server in the farm.

Let's look at a typical scenario in which all terminal servers in a farm have host resource records in DNS that map to a particular terminal server farm name, say Farm1. Any terminal server in the farm can therefore act as a redirector and process the initial connection requests.

Suppose a user starts an RDC client, specifying a terminal server farm named Farm1. The client contacts the DNS server to resolve the Farm1 name to an IP address, and the DNS server, which is configured to use round robin to load balance the initial connection requests, returns a list of IP addresses that are registered for Farm1.

The client sends the connection request to the first IP address on the list that is returned by the DNS server. The terminal server with that address acts as the redirector, querying the TS Session Broker server to determine which terminal server the client should log on to. The TS Session Broker server checks its database, and if the user has an existing session, Session Broker returns the IP address of that terminal server. If the user does not have an existing session, Session Broker determines which terminal server in the farm has the lowest load (based on the number of sessions and the relative server weight value) and then it returns the IP address of that particular server.

The redirector sends the client that IP address and the client then sends the connection request to that server, which processes the logon request and notifies TS Session Broker of the successful logon.

Note that while any load-balancing mechanism can be used to distribute the initial connections, DNS round robin is the easiest mechanism to deploy. However, be aware that DNS round robin does have some limitations, including the caching of DNS requests on the client, which can result in clients using the same IP address for each initial connection request, and the potential for a 30-second timeout delay if a user is redirected to a terminal server that is offline but still listed in DNS.

Deploying TS Session Broker Load Balancing with a network level load-balancing solution such as NLB or a hardware load balancer avoids the limitations of DNS while still taking advantage of TS Session Broker features. The TS Session Broker load-balancing feature lets you to assign a relative weight value to each server, which helps to distribute the load between more powerful and less powerful servers in the farm. For example, if you had a server that could handle twice as many sessions as another server in the farm, you would give that server a 200 weight relative to the other at 100.

TS Session Broker Load Balancing sets a limit of 16 for the maximum number of pending logon requests to a particular terminal server. This feature helps to prevent overwhelming a single server with new logon requests when, for example, you add a new server to the farm or when you enable user logons on a server where they had been previously denied.

Additionally, a new "server draining" mechanism is provided that lets you prevent new users from logging on to a terminal server that is scheduled to be taken down for maintenance. If new logons are denied on a particular terminal server, TS Session Broker will allow users with existing sessions to reconnect, but will redirect new users to terminal servers that have been configured to allow new logons.

For more information, see the "TS Session Broker Load Balancing Step-by-Step Guide" at go.microsoft.com/fwlink/?LinkID=92670. There's not enough space here for me to talk more about the new features of Windows Server 2008 TS. However, there is much more content, including in-depth webcasts, on the Terminal Services Web site. In order to learn more, you should head over to technet.microsoft.com/ts.

Joshua Schnoll has more than 15 years of marketing and technology experience, focusing the last 6 years on server-based computing. He is the worldwide Senior Product Manager for Windows Server Terminal Services. Before coming to Microsoft, he held several positions with Sun Microsystems, including driving product marketing for Sun Ray ultra-thin clients.