Deploying Windows Server 2008 Terminal Services at Microsoft

Technical White Paper

Published: February 27, 2008

On This Page

Executive Summary
Introduction
Windows Server 2008 Terminal Services
Best Practices
Conclusion
For More Information

Executive Summary

Like many large organizations, Microsoft has a geographically dispersed work force. With more than 78,000 employees in 78 countries worldwide, Microsoft faces continual challenges with making corporate information easily available to workers from remote locations and with ensuring that important internal company information is as secure as possible.

Although the vast majority of Microsoft employees have individual personal computers available from which to access company resources, the following two situations frequently occur at Microsoft:

• Staff members need to access internal company resources from home or from a remote location.
• Staff members who are involved in meetings or presentations at remote locations require quick access to internal company resources.

These resources may include any of the following:

• Documents that are located on internal servers at Microsoft.
• Internal business programs that are available only from inside the corporate network.
• Personal workstations that contain important files or programs. For example, developers at Microsoft often need to connect to their individual workstations from remote locations to access programming tools or code.

To meet these requirements, Microsoft maintains a Windows® Terminal Services environment. This environment enables staff members to log on to the Microsoft corporate network and then access terminal servers that are running various internal business applications.

With the development of Windows Server® 2008, the Microsoft Information Technology (Microsoft IT) department wanted to test the new features and functionality of the Windows Server 2008 Terminal Services component to determine whether these features could meet the requirements of a large corporate environment.

Developers and staff at Microsoft have a long history of participation in a development methodology that is known as "eating your own dog food." This type of development methodology means that the products that Microsoft develops are first tested in its own corporate environment. This has the benefit of providing the feedback that only a real-world corporate environment can achieve, as well as providing urgency for the development of stable, reliable, and capable products. With an annual revenue of more than $51 billion dollars U.S., Microsoft is severely affected by any software problem that may occur when it runs its business on these new technologies.

To this end, the Business Online Services Delivery Group at Microsoft IT deployed Windows Server 2008 Terminal Services in a pilot project in four separate locations at Microsoft. The purpose of this implementation was to help make sure that Windows Server 2008 Terminal Services met the requirements of large corporate environment, together with enhancing the overall end-user experience with Terminal Services. This pilot project exceeded the expectations of the deployment team and was so successful that it did not end. Instead, the Terminal Services deployment is being integrated into the Microsoft IT production environment.

This document shares the experiences of the deployment team in the deployment of Windows Server 2008 Terminal Services at Microsoft. Also, because of the experience that the team gained during the deployment, this information should provide meaningful guidance to organizations that want to deploy Windows Server 2008 Terminal Services in both small and large terminal server environments.

This document is intended for enterprise business decision makers, technical decision makers, IT architects, and deployment managers. Although this document provides recommendations based on Microsoft IT early-adopter experiences, it is not intended to serve as a procedural guide. Each enterprise environment has unique circumstances. Therefore, each organization should adapt this information to meet its specific requirements.

Introduction

When considering Microsoft products and technologies, corporate decision makers often request information about experiences with using these products and technologies within Microsoft. Microsoft IT not only provides IT services for Microsoft but also acts as the first customer for each new release of server and business productivity software. Because Microsoft IT requirements are among the most technically challenging in the world, the methods that Microsoft IT uses to deploy these technologies and the experience that Microsoft IT gains from these deployments often provide meaningful deployment and operational guidelines for other organizations that want to deploy Microsoft products. Additionally, because Microsoft IT works with these Microsoft products from the prerelease editions to the Release to Manufacturing (RTM) editions, Microsoft IT provides valuable feedback about features and functionalities. This feedback not only improves the software products throughout their development, but also helps Microsoft customers and partners successfully deploy these products and technologies.

Overview of Terminal Services at Microsoft

Before the implementation of Windows Server 2008 Terminal Services, Microsoft IT relied on three internal Terminal Services deployments. These deployments were Windows Server 2003-based terminal server farms. Because the Windows Server 2003-based terminal server farms did not include the functionality to act as a remote access solution, users could only access the terminal servers from inside the internal corporate network. To access a terminal server from a remote location, a user first had to establish a virtual private network (VPN) connection to the internal corporate network, and then connect to a terminal server.

Because of the security authentication mechanisms that are used to access the internal network at Microsoft, users who did not have access to appropriately configured computers could not access the internal network. Therefore, sometimes users were unable to take advantage of the resources that were available in a terminal server farm.

Additionally, only a few applications were available for use on the terminal servers. These applications included the following:

• Microsoft® Office System programs such as Microsoft Office Word 2003, Microsoft Office Excel® 2003, Microsoft Office PowerPoint® 2003, and Microsoft Office InfoPath® 2003
• Approximately seven internal business applications
• A desktop environment that includes the ability to browse the internal network

Because of the limited number of applications that were available in a terminal server farm, because of the restricted access to a terminal server farm, and most importantly, because the majority of users at Microsoft work from their individual desktop computers, the Windows Server 2003-based terminal server farms saw relatively little usage. Between 30 and 40 people took advantage of the available resources each month. Generally, users would only log on to a terminal server to file or update a bug, to open a document by using a Microsoft Office program, or to perform a particular task that they could not perform on a desktop computer.

Windows Server 2008 Terminal Services

The deployment team had to perform general testing of Windows Server 2008 Terminal Services to make sure that the features and the functionality of the Terminal Services component met those that are available in the Windows Server 2003-based terminal server farms. However, the team felt that the new features that are available in Windows Server 2008 would enable it to move the usage of Terminal Services beyond that of the Windows Server 2003-based terminal server farms. The team determined that Instead of acting in only an application hosting role, the Windows Server 2008-based Terminal Services environment could act as a security-enhanced and scalable remote access solution at Microsoft. Therefore, the team had three overriding goals throughout the pilot project:

• To test and validate the Terminal Services Gateway (TS Gateway) concept
• To test the scalability and the manageability of a Windows Server 2008-based terminal server farm
• To increase the security of resources on the corporate network by using Terminal Services

Although these goals were the overarching focus of the pilot project, the team also wanted to test Windows Server 2008 features and functionality that focus on enhancing the end-user experience with Terminal Services. These tests focused on implementing and gathering feedback for the following features:

• Terminal Services RemoteApp™ (TS RemoteApp). This feature enables a Terminal Services application to run in its own window on the client desktop. This capability gives an end user a seamless experience when using Terminal Services applications.
• Terminal Services Easy Print. Historically, it had been difficult to print from a Terminal Services application to a local printer. In this scenario, the printer driver for the particular client printer had to be installed on the terminal server. The Terminal Services Easy Print feature enables a user to easily print from a Terminal Services application to a printer that is connected to the local computer.

Although the primary focus of the Terminal Services pilot project was on the new features and functionality in Windows Server 2008, the team also had to remain cognizant of the requirement to provide general networking resources to users who do not have a desktop computer available. The requirement for a Terminal Services environment from which users can perform general day-to-day tasks, such as opening a document from a Windows SharePoint® Services site or changing a domain password, has not changed at Microsoft.

Terminal Services Gateway

The TS Gateway feature was introduced with Windows Server 2008. TS Gateway is one of the main features that the team wanted to test. The team determined that a successful implementation of TS Gateway was a key component of creating an easy-to-use universal remote access solution by using Terminal Services. Additionally, the team determined that the stability and manageability of this feature would be critical to the overall scalability of a Windows Server 2008-based terminal server farm.

TS Gateway is a Web server component. It provides the following primary functionalities:

• It acts as the endpoint of a Secure Sockets Layer (SSL) connection from a Terminal Services client. This feature allows for a connection from the Internet to any Remote Desktop-enabled computer.

  Note: The destination resource can be a terminal server farm, a terminal server in a lab environment, or even a desktop computer.

• It performs authentication and authorization of the connecting user to determine whether the user is permitted to access the terminal server farm.
• It performs authorization of the remote computer from which the user initiates the Terminal Services session to determine whether the connection is allowed.
• It forwards the user's connection to the destination resource by using Remote Desktop Protocol (RDP).

To perform these actions, the TS Gateway component listens on the Hypertext Transfer Protocol over SSL (HTTPS) port for Terminal Services clients. The Terminal Services client encapsulates the RDP traffic in Remote Procedure Call (RPC) over HTTPS and then sends the encapsulated traffic to the TS Gateway server. The TS Gateway component unpacks the RDP traffic, creates a session to the destination resource, and then submits the RDP traffic.

Figure 1 illustrates the traffic flow between a Terminal Services client computer and a terminal server via TS Gateway.

Figure 1. TS Gateway connection

Formerly, Microsoft IT experienced limited usage of its terminal server farms by remote users. This was because of the requirement to create an initial VPN connection to the internal network. By using TS Gateway, the team expected to achieve the following goals:

• Users who are in corporate environments that do not permit outbound VPN connections could now connect to a terminal server at Microsoft. This is because most environments allow outbound Hypertext Transfer Protocol (HTTP) and HTTPS connections.
• Users would be more likely to use TS Gateway as a remote access solution because of its simplicity and speed. Sometimes, establishing a VPN connection can take a long time. Additionally, VPN connections are less tolerant of network delays than are SSL connections. By using RDP encapsulated in HTTPS, users could experience quicker access to the corporate resources at Microsoft. This is because the HTTPS connection has lower bandwidth requirements than a VPN connection, and HTTPS connections have a higher tolerance to network delays.

By using TS Gateway, the deployment team determined that it could make internal corporate resources available to anyone who could make an outbound SSL connection to the Internet.

The deployment team developed the following plan to deploy and test TS Gateway:

1. Deploy a single TS Gateway environment.
2. Perform the required security tests to verify that the deployment meets the security requirements at Microsoft IT.
3. Open the TS Gateway to a few hundred users to obtain feedback on the usability and stability of the product.
4. Extend the number of TS Gateway deployments to meet the requirements of a large enterprise.

Terminal Services Gateway Deployment

In July 2005, the deployment team deployed the first stage of the Windows Server 2008 Terminal Services pilot. This deployment consisted of a single TS Gateway environment that consists of computers that have the following characteristics:

• Two TS Gateway computers that are configured as follows:
• Two 2.2-gigahertz (GHz) AMD Opteron CPUs
  • Four gigabytes (GB) of random access memory (RAM)
• Five terminal servers that are configured as follows:
  • Two 2.2-GHz AMD Opteron CPUs
  • Four GB of RAM
• One Terminal Services Session Broker (TS Session Broker) computer that is configured as follows:
  • Two 2.2-GHz AMD Opteron CPUs
  • Four GB of RAM

Figure 2 illustrates the configuration of the initial TS Gateway deployment.

Figure 2. Initial TS Gateway configuration

The team initially made this deployment available to members of the Terminal Services development group. This deployment gave the initial TS Gateway configuration a load of approximately 200 users.

This deployment was very popular with the Terminal Services development group. It enabled users to access their workstations and other internal resources from virtually any location. Also, by using the TS Gateway deployment, the developers found that they could connect to the corporate network much more quickly than they could by using a VPN connection.

Extending the Deployment

Although the initial TS Gateway deployment provided valuable feedback to the deployment team, the team wanted to increase the size the TS Gateway deployment to that which is required in a large enterprise environment. This kind of deployment would stress Windows Server 2008 Terminal Services with regard to scalability, redundancy, and manageability. The team wanted to determine how well Windows Server 2008 Terminal Services operated with regard to the various load-balancing options that are available. To do this, the team had to test TS Gateway both with the Windows Server 2008 Network Load Balancing (NLB) service and with third-party hardware load-balancing devices.

To this end, the deployment team expanded the Terminal Services deployment to that of four sites worldwide. This expanded Terminal Services deployment has the following characteristics:

• Ten servers that are running TS Gateway
• Nine terminal servers
• Three servers that are running TS Session Broker

This expansion gave the Terminal Services deployment team the following kind of environment with which to test the scalability and the manageability of the TS Gateway feature:

• One Windows Server 2008-based NLB cluster
• Three hardware load-balancing clusters

Figure 3 shows the worldwide Windows Server 2008 Terminal Services deployment.

Figure 3. Worldwide Terminal Services deployment

To test the expanded Terminal Services deployment, the deployment team extended the availability of the Terminal Services deployment to multiple development teams. This extension introduced the Terminal Services pilot to the traffic from more than 2,000 developers. Next, the deployment team made the deployment available to other groups at Microsoft.

To promote the use of terminal server applications, the team made many more applications available on each terminal server farm than were available on the Windows Server 2003-based terminal server farms. Currently, approximately 30 terminal server applications are available.

After deploying the terminal server applications, and after making the Windows Server 2008-based terminal server farms available to other corporate users, the Terminal Services deployment team experienced much greater usage of the Terminal Services environments. Currently, the Windows Server 2008 Terminal Services deployment experiences usage from approximately 7,500 users worldwide.

Table 1 shows some of the usage statistics that three of the Terminal Services deployments experienced. These statistics are gathered from Terminal Services sessions that lasted longer than 60 seconds and reflect loads that the Terminal Services deployment experienced over a particular one-month period.

Table 1. Terminal Services Usage Statistics*

* Statistics gathered December 1, 2007 to December 31, 2007

Table 2 shows the load statistics for the same Terminal Services deployments over the same one-month period.

Table 2. Terminal Services Load Statistics*

* Statistics gathered December 1, 2007 to December 31, 2007

The team took advantage of the different characteristics of the worldwide Terminal Services deployments together with the additional usage loads to test the scalability of the TS Gateway feature, particularly with regard to load balancing.

Terminal Services Gateway Load Balancing

TS Gateway is supported for use with various load-balancing solutions. Therefore, a critical part of validating the TS Gateway concept was that of determining how well TS Gateway performed on an NLB cluster that is under various loads. This validation included the following tests:

• Determine how well TS Gateway performs on a Windows Server 2008-based NLB cluster.
• Determine how well TS Gateway performs in a third-party load-balancing environment.

To perform these validation tests, the deployment team tested a TS Gateway NLB cluster under various loads. The deployment team tested the TS Gateway on a two-node Windows Server 2008 NLB cluster. This NLB cluster uses two Windows Server 2008-based computers that are each configured as follows:

• Two 2.2-GHz AMD Opteron CPUs
• 4 GB of RAM

The team found that a single cluster node could host 700 simultaneous connections without being overloaded, with an approximate maximum of 1,300 simultaneous connections. From these results, the team determined that a two-node NLB cluster could host approximately 1,500 simultaneous connections with a maximum of 2,600 simultaneous connections. From a fault-tolerance point of view, and as a best practice, the team determined that to support 1,500 TS Gateway connections, an NLB cluster should have at least three cluster nodes. This is because although one cluster node can easily handle 700 connections, an administrator might experience the following issue if there are 1,500 connections among only two cluster nodes:

If one of the cluster nodes experiences a hardware failure, the remaining node would have to host all 1,500 connections. The team determined that this number of connections could exceed the capacity of the remaining cluster node. On an NLB cluster that has three nodes, any two nodes can easily handle the traffic of 1,500 Terminal Services sessions.

The team used two-node NLB clusters in the TS Gateway deployment. The team determined that although the number of cluster nodes could be easily extended, additional cluster nodes would not change the number of supported connections appreciably. The team determined that the main issue that limits using an NLB cluster together with TS Gateway is not the number of cluster nodes that are available. Instead, the main issue is the overall traffic that an NLB cluster handles. If the NLB cluster is under a heavy load, it may eventually experience issues with convergence and with synchronizing the cluster nodes. From the tests that the team performed, it determined that an NLB cluster could handle the traffic that 1,500 connected users generate.

Figure 4 illustrates the network flow with TS Gateway and Network Load Balancing.

Figure 4. TS Gateway load balancing

In this figure, RPC traffic passes among the TS Gateway computers. This process illustrates a load-balancing feature that TS Gateway includes.

Every logical RDP connection that is encapsulated in SSL consists of two physical SSL connections. Therefore, in a load-balancing environment, a situation could occur in which one SSL connection that is part of a logical RDP connection is sent to one TS Gateway computer, and the other SSL connection is sent to another TS Gateway computer. In this situation, the TS Gateway computer that receives the second SSL connection automatically redirects the RDP traffic to the TS Gateway computer that received the initial SSL connection. The team found that this feature enabled the use of Network Load Balancing without the requirement of Internet Protocol (IP) affinity. Additionally, the team found that this feature enabled the TS Gateway farm to efficiently balance loads in which many clients connect from an organization that has only one external IP address.

After testing TS Gateway in a Windows Server 2008-based NLB environment, the team performed additional load tests by using third-party load-balancing devices. The team determined that for a TS Gateway farm that experiences more than 1,500 simultaneous connections, a third-party load-balancing device is the best solution.

Terminal Server Load Balancing

The team also deployed the Windows Server 2008-based terminal server farms in load-balanced configurations. To configure load balancing for each terminal server farm, the team used a typical Domain Name System (DNS) round-robin configuration together with the new load-balancing functionality that was introduced in the Windows Server 2008 TS Session Broker component.

TS Session Broker is a Windows Server 2008 Terminal Services component that builds on the functionality that is available in the Windows Server 2003 Terminal Services Session Directory component. TS Session Broker is a supplementary Terminal Services role that provides load-balancing functionality and user session management to a Windows Server 2008-based terminal server farm. TS Session Broker provides the following two main functions:

• It directs a disconnected and then reconnected session to the correct terminal server.
• It directs new sessions to the terminal server that has the fewest Terminal Services sessions.

This functionality gives TS Session Broker the same user reconnection functionality that is available in Windows Server 2003, together with some load-balancing functionality. For example, consider the following scenarios:

• A client connects to a terminal server in a terminal server farm that contains two terminal servers. Then, the client is disconnected from the session. In this situation, the user's programs remain running on the terminal server but the client session goes to a disconnected state.

  When the client reestablishes the connection to the terminal server farm, TS Session Broker reconnects the client to the terminal server from which it disconnected.

• A new client connects to the terminal server farm. In this situation, TS Session Broker contacts the terminal servers in the terminal server farm to determine which server has the fewest Terminal Services sessions. Then, TS Session Broker directs the client connection to the least busy server.

To perform these actions, TS Session Broker keeps a list of all the logged-on users together with the corresponding terminal server to which each user is connected. When a user logs on to a terminal server farm, the TS Session Broker receives a query that resembles the following:

Where is user X?

TS Session Broker responds to this query by using one of the following responses:

• User X is on terminal server Y.
• User X is not found on the terminal server farm, and the least busy server is Y.

The team determined that it could use the TS Session Broker load-balancing functionality to create the terminal server farms in its worldwide deployments without having to use any additional load-balancing solution. The team used a single TS Session Broker computer in each of three of its Terminal Services deployments. The following process occurs in a terminal server load-balancing scenario:

1. A user establishes an SSL connection to a TS Gateway computer.
2. The TS Gateway computer submits a DNS request to a DNS server to locate the IP address that corresponds to the host name of the terminal server.
3. The DNS server responds by using a round-robin response. In this scenario, the DNS server responds to the DNS request by returning the next IP address in a list of IP addresses that are assigned to the submitted host name.
4. The TS Gateway computer directs the RDP traffic from the user's session to the particular terminal server that the DNS server specified.
5. The terminal server submits a request to the TS Session Broker computer.
6. The TS Session Broker computer redirects the user's Terminal Services request to the least busy terminal server.
7. The Terminal Services session is established with the destination terminal server.
8. The user's profile is loaded into the Terminal Services session.

Figure 5 illustrates this process.

Figure 5. Load balancing in a terminal server farm

Although the TS Session Broker component may be installed on a terminal server, the team determined that for an enterprise Terminal Services deployment, it is best to run TS Session Broker on a separate computer. This enables the team to easily exclude any terminal server from the terminal server farm for maintenance purposes. The team can then install updates on any of the terminal servers while still having the terminal server farm available to end users.

The Windows Server 2008-based NLB cluster tests proved so successful that currently, one of the most heavily loaded TS Gateway deployments in the production environment at Microsoft runs on a Windows Server 2008-based NLB cluster. Additionally, TS Session Broker performs so well that Microsoft IT uses TS Session Broker together with round-robin DNS as the only load-balancing solution in three of its four Windows Server 2008-based terminal server farms.

User Experience Enhancements

Although performance and scalability were the team's two focuses in the deployment of Windows Server 2008 Terminal Services, the team also wanted to increase user acceptance and enhance the overall user experience with Terminal Services. The team determined that to encourage more users to take advantage of the ease of access to corporate resources that Terminal Services provided, the team would have to make using the Terminal Services resources as seamless and as easy as possible. Additionally, the team determined that enhancing the user experience with Terminal Services would increase security in the corporate environment.

Microsoft has many users who work remotely or who must access large or sensitive company documents from a remote location. The following scenarios frequently occur at Microsoft:

• Users must open large documents, such as a large Office PowerPoint presentation, from a remote location or over a slower network link. In this situation, opening a document can take a very long time.
• Users must open sensitive company documents from a remote location. In this situation, a user may be more likely to save a copy of the document to the local computer.

The team determined that if the users could easily access applications on a terminal server, and then open the large or sensitive documents on the terminal server, the following benefits would result:

• The users would have quick access to large documents. This speed of access would encourage users to use Terminal Services more often.
• Sensitive documents would be opened and would remain on terminal servers that are inside the internal network. This would enhance the overall security of documents at Microsoft.

The team took advantage of the following two Terminal Services features to work toward this goal:

• Terminal Services Web Access (TS Web Access)
• TS RemoteApp

TS Portal

TS Web Access is a Terminal Services role that enables users to connect to TS RemoteApp applications or terminal server desktops from a Web browser. The team tested this role for use in its Terminal Services deployment. After testing TS Web Access, the team determined that TS Web Access would provide several advantages to Terminal Services users, such as making TS RemoteApp applications easy to find from a Web-based front end.

However, the team decided that for its particular environment, the best approach would be to build a Terminal Services portal application to customize the functionality that is available in TS Web Access. This custom Web access portal is named TS Portal.

The TS Portal application is designed to make end-user access to the Terminal Services environment as intuitive as possible. When a user logs on to TS Gateway, the TS Portal application appears.

Figure 6 illustrates the TS Portal page that appears when a user accesses TS Gateway.

Figure 6. TS Portal home page

Figure 7 shows the TS RemoteApp applications that are available when the user clicks the Applications menu on the TS Portal Web site.

Figure 7. Available TS RemoteApp applications

The TS Portal application gave the Terminal Services deployment a customized user interface—a single location from which users can access terminal server resources.

Terminal Services RemoteApp

TS RemoteApp is a Terminal Services component that is wholly directed toward the end-user experience with terminal server applications. Instead of running within a terminal server desktop, the terminal server application appears in a separate window on the user's desktop. Additionally, other features, such as notification area icons that correspond to the TS RemoteApp application, appear on the user's desktop. The team felt that this technology would enhance the user experience with Terminal Services by providing an almost seamless experience between terminal server applications and the local applications that a user might run on the local desktop.

Therefore, the team deployed many of the most used applications by using the TS RemoteApp feature in Windows Server 2008 Terminal Services. This gave users quick and intuitive access to the most commonly needed applications.

Although the TS RemoteApp feature was very popular with users who were involved in the Terminal Services pilot project, the team did experience some usability issues with the feature. The team found that because the TS RemoteApp user experience was so seamless with the end-user desktops, sometimes a user could forget that he or she was actually running a terminal server application. Therefore, the user might try to drag information from a local application to a TS RemoteApp application, or vice versa. This action would be unsuccessful and could cause a user experience problem. The team found that sometimes it had to provide additional education to users to make them aware that dragging items between terminal server applications and local applications is currently not possible.

The team found the TS RemoteApp-enabled applications to be especially useful for opening or editing large documents. Users experienced almost instant responses when working with large documents that would typically have to be downloaded to the local computer over many minutes. Additionally, the team experienced a sense of increased security with regard to large or sensitive documents because the users tended to work with the documents on the terminal server by using the TS RemoteApp applications. Users were less likely to download the document to the local computer because it was easier and faster to work with the particular document in a Terminal Services environment.

Best Practices

By deploying Terminal Services 2008 in both small and large environments worldwide, the deployment team developed the following best practices that it considers important to the successful deployment of a Terminal Services environment:

• Limit computer-based NLB implementations to TS Gateway deployments that experience 1,500 or fewer simultaneous connections. The team calculated that Windows NLB would work best with a maximum of approximately 1,500 simultaneous connections. Adding more load-balancing servers would not appreciably increase the number of connections that the TS Gateway farm can host. For TS Gateway farms that experience more than 1,500 simultaneous connections, using a third-party load-balancing device is the best approach.
• Deploy three or more NLB nodes to support TS Gateway in an NLB cluster. The maximum number of connections that a single NLB cluster node can support is limited by the CPU resources of that node. Depending on the CPU speed and other hardware resources of each cluster node, the team determined that three or more cluster nodes may be required in an NLB environment with a maximum of 1,500 connections for the whole NLB cluster.
• Install TS Session Broker on a separate computer. The team found that to have the most flexibility in a load-balanced terminal server farm, the TS Session Broker component should run on a separate server. This type of installation enabled the team to take any terminal server offline for maintenance or upgrade purposes without affecting the availability of the terminal server farm. The team found that the hardware resources that the TS Session Broker computer requires are very light. Therefore, the team determined that the TS Session Broker role could be installed on a less capable computer, or the role could be combined with other roles in the organization.

Conclusion

The Terminal Services deployment team intended the Terminal Services deployment to act as a test environment to determine the overall scalability and stability of Windows Server 2008 Terminal Services in a large enterprise. Additionally, the team intended this worldwide deployment to generate feedback with regard to features and functionality to include in the Terminal Services program.

The TS Gateway concept proved to be a popular and scalable remote access solution, enabling users to access the corporate network at Microsoft from virtually any location worldwide. Personnel could use this feature to access important files and resources at Microsoft from locations from which they were unable to do so previously. Additionally, the speed of connecting to resources on the internal network improved to such an extent that users preferred the TS Gateway farm over that of the typical remote access VPN connection.

By using fast and easy-to-access terminal server farms, the team was able to achieve a goal of increasing the security of sensitive internal resources such as internal documents and worksheets.

Although this pilot project was deployed as a test environment, the deployment was so successful, and the user response was so positive, that the Terminal Services pilot did not end. Instead, the whole environment was integrated into the production environment at Microsoft IT. This change means that the worldwide Windows Server 2008 Terminal Services deployment is now handled in the same manner as a typical production environment at Microsoft.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

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.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2008 Microsoft Corporation. All rights reserved.

Microsoft, Excel, InfoPath, PowerPoint, RemoteApp, SharePoint, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.