A Service Development and Planning Guide

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Archived content - No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

On This Page

Project Overview
Vision/Scope Approved Milestone
Project Plan Approved Milestone
Scope Complete/First Use Milestone
Release Milestone
Resources

Project Overview

Overview

Deploying Microsoft Windows NT Server version 4.0, Terminal Server Edition

This service guide provides a process for designing an implementation and deployment of Microsoft® Windows NT® Server version 4.0, Terminal Server Edition (referred to as Terminal Server in this guide).

This guide illustrates steps for deploying Terminal Server in an enterprise environment. It contains information on assembling a project team, assessing the current environment, designing a solution based on need, testing, piloting, and implementing a full deployment. By following the recommendations set forth in this guide, you can provide users with the functionality of Windows NT and access to applications based on Microsoft® Windows® in a mixed-client environment, including Windows-based terminals, legacy desktops (Windows- and non-Windows-based), and 32-bit Windows-based desktops.

Applying Core MSF Principles

Structurally, the guide offers project plan guidance based on the core principles of Microsoft Solutions Framework (MSF) and built around the four MSF milestones—Vision/Scope Approved, Project Plan Approved, Scope Complete/First Use, and Release.

Getting To Know Terminal Server

Introducing Microsoft Windows NT Server 4.0, Terminal Server Edition

Microsoft Windows NT Server 4.0, Terminal Server Edition is an extension of the Windows NT product line that provides support for remote access by using thin client software that runs on a new class of Windows-based terminals and on desktop systems running under 16-bit and 32-bit Windows. Terminal Server allows users to run both the Windows desktop operating system and Windows-based applications directly off the server, extending the scalable Windows family and providing users of low-cost terminal devices and legacy hardware with access to the latest Windows NT–based technology and the latest Windows-based applications.

Terminal Server has three parts. The server itself is a new edition of Microsoft Windows NT Server 4.0 with the ability to host multiple, simultaneous client sessions. Remote Desktop Protocol (RDP) is the protocol that allows a super-thin client to communicate with Terminal Server over a network. Terminal Server Client is a super-thin client application that connects to Terminal Server from a Windows-based terminal, Microsoft Windows for Workgroups 3.11, Microsoft Windows 95 or Windows 98, or Windows NT.

Terminal Server includes Microsoft® Internet Explorer version 4.01 for Web and file system browsing. Active Desktop is not supported in the current release of Terminal Server.

Consult the Start Here and Administration Guide documentation that comes with the Terminal Server software for complete instructions on installing and administering Terminal Server. You can find electronic copies of these documents on the Terminal Server installation CD-ROM at \support\books.

For the latest Terminal Server product information, tours, and file downloads, visit the Terminal Server home page at https://www.microsoft.com/ntserver.

Determining Business Drivers

Customers who have made the decision to implement Terminal Server typically explain their decision in terms of business drivers. Although not all customers focus on the same set of drivers or give them all the same degree of consideration, a well-implemented Terminal Server deployment will often confer benefits upon the user that exceed those planned for during the initial decision-making process.

Typical business drivers for Terminal Server include administration and network usage, legacy client device replacement, cross-platform compatibility, and Year 2000 issues.

Administration and Network Usage

Terminal Server can improve and simplify administration while also optimizing performance over the network.

• Terminal Server centralizes administration of network resources by putting all applications on servers rather than distributing them to individual desktop computers. This is particularly useful with bandwidth-intensive applications like flat-file systems (for example, Microsoft® FoxPro®). Terminal Server clients can efficiently gain access to an application running on Terminal Server and a fast network segment because of the architecture's efficient use of bandwidth. All application processing takes place on the server, with only video, mouse, and keyboard traffic passing between the client and Terminal Server.

• Deploying applications centrally on Terminal Server allows users simultaneous access to upgraded applications. Administrators can deploy custom applications that require frequent incremental upgrades on servers running Terminal Server, significantly reducing time and labor to update the applications for all users.

• Users can store sensitive data in a central data facility (glass house) rather than on their individual personal computers, substantially decreasing the risk of data loss from theft, natural disasters, and other causes.

• Remote users can gain access to the same data and applications as local users over dial-up or permanent Internet connections and benefit from how Terminal Server efficiently uses bandwidth.

Terminal Server system diagram

Legacy Client Device Replacement

Terminal Server simplifies the process of replacing legacy hardware and software. If the organization currently uses text-based terminals, it can deploy Terminal Server with a new low-cost, thin client device known as a Windows-based terminal to provide an upgrade path to Windows-based applications.

An organization can also easily install Terminal Server client software on older personal computers used for task-based applications such as terminal emulation or fixed function applications. In this way, end users can obtain access to the 32-bit Windows-based user interface found on Windows 95 and 98 or Windows NT 4.0 and to the latest Windows-based applications before they receive new computers.

• Companies with high employee turnover or seasonal or temporary workers can decrease training costs with Terminal Server because they can replace legacy text-based applications using unfamiliar and non-intuitive user interfaces with newer applications using the familiar Window-based user interface.

• Many older business applications and development tools are no longer supported by the companies that released them, cannot be upgraded easily, and are often unfamiliar to today's technical support staff. Terminal Server provides an efficient way to replace these obsolete programs and tools with off-the-shelf Windows-based applications and tools.

• Terminal Server provides a smooth migration path because users with legacy software or hardware can gain access to new applications through the Terminal Server interface. For example, as an organization upgrades from Office version 4.3 to Office 97, users can run older versions of Windows while taking advantage of the latest version of the application prior to a system refresh.

Cross-Platform Compatibility

Users of non-Windows–based computing platforms such as Apple® Macintosh®, UNIX, and Microsoft® MS-DOS® can gain access to Terminal Server by using vendor add-on client/server software such as MetaFrame from Citrix Systems. By doing so, an organization can deploy one set of applications and one user interface across all client devices.

• Organizations can lower training and administrative costs by training users on applications and interfaces together, regardless of platform. In addition, administrators can use Terminal Server to centrally manage applications and system configurations for users of all platforms.

• By using Terminal Server, a company with mixed desktop environments can deploy common e-mail clients, productivity suites, or other applications to every user while users continue to operate under their individual platforms for job-specific tasks. Thus, the company benefits from the wide range of Windows-based applications without having to replace all desktops.

See Planning Client Deployment in the "Project Plan Approved Milestone" section for more information on using vendor client software with Terminal Server.

Year 2000 Issues

Institutions struggling with year 2000 (Y2K) compliance can use Terminal Server as part of their rapid replacement strategy. This strategy will enable the organization to continue using current hardware while implementing a long-term solution.

• Older personal computers often have basic input/output systems (BIOSs) on their motherboards that are not Y2K-compatible, which will cause system dates to render incorrectly. Companies can deploy Terminal Server Client on these computers, allowing them to be used as Terminal Server workstations until the computers or motherboards can be replaced. If the hardware running Terminal Server itself is Y2K-compliant, users can take advantage of the Terminal Server architecture's server-side processing to avoid Y2K problems on the client side.

• Companies can deploy Y2K-compliant applications quickly by installing them on servers running Terminal Server. Users can discard non-compliant applications and use the newer versions on Terminal Server until applications are deployed throughout the organization.

Note that running a Y2K-compliant operating system does not imply the compliance of any applications running on it. Consult individual application vendors for information on Y2K compliance.

Using Examples

Many of the principles and processes in this guide will be illustrated with examples from a fictitious car rental company called Rent-a-Car, Inc. Most of the sample documents in the Resources section are based on this fictitious company.

Examples are presented in italics.

Rent-a-Car, Inc. (RACI), was founded in 1985 to service the needs of the vacation renter. Although demonstrating lackluster performance for its shareholders throughout the 1980s, RACI experienced explosive growth during the 1990s by following a growth-through-acquisition policy and by continuing to target the cost-sensitive leisure renter. By the end of 1997, RACI not only had offices nationwide but had opened or acquired reservation and rental stations throughout Europe and South America .

Unfortunately for RACI's shareholders, several issues loomed on the horizon that threatened to impact the company's increasing profits. RACI's chief information officer was particularly concerned about the following issues related to information technology that threatened the mission-critical reservations department:

• "Green screen" replacement. By investing all available capital in new acquisitions, RACI had neglected its information systems for several years. Employees at RACI's reservations center in Atlanta still used general-purpose, text-based "green screen" terminals to gain access to the corporate mainframe. The cost of maintaining and supporting this system was increasing at an accelerating rate.

• Non-Windows-based hardware and operating systems. Multiple acquisitions had left RACI with hardware from many different vendors and eras. Several managers at the reservation center were using Apple Macintosh computers. This situation threatened the planned rollout of a personal computer–based Microsoft® Visual Basic® application for human resource scheduling.

• Vendor and remote access . Large travel agencies, both in North America and abroad, expressed an interest in obtaining low-cost, secure, and direct access to the RACI Rent-a-Car reservations system. Several managers also requested remote access so that they could check on such things as reservation center call volume and call wait time during off-hours.

• Year 2000 problems. RACI had approximately 1,000 users throughout the company using legacy hardware running Microsoft Windows for Workgroups. Information Systems (IS) determined that the system BIOS on many of these machines were non-Y2K compliant. Because of a shortage of IS personnel and the urgency of several mission-critical issues, RACI was concerned that they would not be able to replace hardware for all of these users by January 2000.

At the direction of the CEO, Rent-a-Car's chief information officer funded an Infrastructure Renewal Project to determine how these issues could be resolved with minimal impact to RACI's operations or bottom line. The company approached a consulting organization to assist with this project.

Preparing To Use This Guide

Knowing What You Need To Know

This guide assumes that you have at least a working knowledge of the following systems and disciplines:

• Microsoft Windows NT Server 4.0.

• TCP/IP and Microsoft TCP/IP services for dynamic host configuration protocol (DHCP), Windows Internet Name Service (WINS), and Domain Name System (DNS).

• The fundamentals of networking in an enterprise environment.

• Novell NetWare, if you are working in a NetWare environment.

Finding More Information

Microsoft Press® publishes books and training materials that can help you learn more in these areas. In addition, Microsoft Authorized Technical Education Centers (ATECs) offer instructor-led, self-paced, and online courses in using and deploying Microsoft software. Visit the Microsoft Training and Certification Web page at https://www.microsoft.com/learning/default.asp to find an ATEC near you and select a course of study appropriate to your needs.

Training Resources

Subject	Resource
Windows NT Server 4.0	Running Microsoft Windows NT Server 4.0 (Microsoft Press, 1997) Microsoft Windows NT Server 4.0 Resource Kit (Microsoft Press, 1996) Windows NT Training Kits from Microsoft Press https://www.microsoft.com/learning/books/certification ATEC Class 803: Administering Microsoft Windows NT 4.0 ATEC Course 688: Internetworking Microsoft TCP/IP on Microsoft Windows NT 4.0 ATEC Course 922: Supporting Microsoft Windows NT 4.0 Core Technologies The Microsoft Windows NT Server Web page https://www.microsoft.com/ntserver
Terminal Server	Terminal Server user documentation ATEC Course 1198: Supporting Microsoft Windows NT Server 4.0, Terminal Server Edition Microsoft Windows NT Server Web page https://www.microsoft.com/ntserver/
TCP/IP	Microsoft TCP/IP Training (Microsoft Press, 1997) ATEC Course 688: Internetworking Microsoft TCP/IP on Microsoft Windows NT 4.0
Networking Fundamentals	Networking Essentials, Second Edition (Microsoft Press, 1997) ATEC Course 578: Networking Essentials

Using This Guide

Using Milestone-Based Planning

This planning guide follows the Microsoft Solutions Framework deployment-planning model for designing and implementing group projects. See Service Guide Fundamentals in the Resources section (Included in self-extracting file Tsdeploy.exe as Service Guide Fundamentals.doc) for more information about how MSF core principles are applied to planning guides.

Ordering of Activities

Although the activities leading to each milestone have a logical progression, they need not take place in the order stated. Different team members can perform activities concurrently, to leverage resources of people, time, and money.

Use your best judgment and knowledge of the organization as guides to deciding the optimal time to work on any specific activity. To maximize project efficiency, however, you should not change the sequence in which the four milestones are reached.

Using the Deployment Process Flowchart

The following flowchart offers another high-level view of this service guide's approach to developing a process for deploying Terminal Server. The flowchart highlights the major activities and tasks and their associated milestones and key deliverables that are important for the entire project team.

A copy of Terminal Server Deployment Flowchart can also be found in the Resources section (Included in self-extracting file Tsdeploy.exe as Flowchrt.vsd).

Deployment process flowchart

Using the Roadmap

The roadmap provides a different, high-level overview of a project. It includes:

• Activities that are necessary to complete project deliverables and advance to the next milestone.

• Resources that are necessary to complete each activity and create project deliverables.

• Deliverables resulting from activities that are necessary to complete a timely and effective project.

Use this roadmap to gain a comprehensive visual perspective of how the project team must prepare itself to undertake this project. It lists all activities and deliverables. However, only the high-level resources are listed; see the appropriate section for more details. Gray highlighted areas in the left column denote the four milestones.

You can also refer to the roadmap in the Resources Included in self-extracting file Tsdeploy.exe as Roadmap.doc).

Terminal Server Roadmap

Milestone	Activity	Resources	Deliverables
Vision/Scope Approved	Identifying key team members	MSF Reference Guide Click here	Project team
	Defining vision and scope	Sample Vision/Scope Document Included in self-extracting file Tsdeploy.exe as Sample Vision-Scope.doc	Vision/scope document
	Assessing risk	Sample Risk Assessment Matrix Included in self-extracting file Tsdeploy.exe as Risk Assessment Matrix.doc	Risk matrix
	Defining project structure	Information in text	Project structure document
	Approving the vision/scope	Sample Vision/Scope Document Included in self-extracting file Tsdeploy.exe as Sample Vision-Scope.doc	Approved vision/scope
Project Plan Approved	Documenting the environment	Sample Environment Analysis D Included in self-extracting file Tsdeploy.exe as Sample Environment Assessment.doc	Current environment analysis
	Creating a functional specification	Microsoft Solutions Foundation Web site https://www.microsoft.com/learning/default.asp	Functional specification
	Creating/approving the logical design	Sample Logical Design Included in self-extracting file Tsdeploy.exe as Sample Logical Design.doc	Logical design
	Creating/approving the physical design	Sample Physical Design Included in self-extracting file Tsdeploy.exe as Sample Physical Design.doc	Physical design
	Reviewing the risk assessment	Sample Risk Assessment Matrix Included in self-extracting file Tsdeploy.exe as Sample Risk Assessment Matrix.doc	Risk assessment matrix
	Building the master project plan	Microsoft Solutions Foundation Web site /learning/default.asp	Master project plan document
	Approving the master project plan	Microsoft Solutions Foundation Web site https://www.microsoft.com/learning/default.asp	Approved project plan
Scope Complete/ First Use	Validating the plan	Information in text	Test lab built and Terminal Server tested
	Developing a pilot implementation plan	Information in text	Pilot implementation plan
	Deploying the pilot server	Information in text	Server deployed in pilot environment
	Deploying applications on the pilot server	Information in text	Applications deployed on the server
	Piloting Terminal Server	Information in text	Pilot users using Terminal Server
	Assessing the pilot deployment	Sample Pilot Deployment Assessment Included in self-extracting file Tsdeploy.exe as Sample Pilot Assessment.doc	Pilot deployment assessment
Release	Deploying Terminal Server throughout the environment	Information in text	Terminal Server deployed throughout environment
	Assessing the complete deployment	Sample Deployment Assessment Included in self-extracting file Tsdeploy.exe as Sample Deployment Assessment.doc	Deployment assessment
	Planning ongoing maintenance, support, and scalability	Information in text	A stable, scalable Terminal Server infrastructure

Service Guide Conventions

Service Guide Organization

Service guides are organized by the milestone-based MSF process model so you can quickly and easily locate specific content. Each section begins with an overview that describes milestone activities, resources required to perform these activities, and deliverables produced by these activities.

Side Art

Side art is a collection of callout graphics located in the left margin of service guide pages. They alert you to specific critical issues, important information, and handy tips. Use side art as a quick and easy way to identify critical elements of this guide that prompt specific decisions or actions.

Side Art

Side art	Title	Definition
	Caution	Specific points where incorrect decisions can lead to problems.
	Guideline	A suggested method of operation or implementation. Also, a rule, tip, or hint designed to facilitate activity achievement.
	Microsoft Solutions Framework	A particular model, concept, or guideline that is part of Microsoft Solutions Framework and is used to plan, build, and manage distributed computing systems.
	Notes	An identified exception or unique circumstance of a particular situation.
	References	Books, white papers, vendor Web sites, and Microsoft URLs.
	Tools	Specific applications (specialized software, templates, or checklists, for example) that facilitate activity completion.

Important Terms

This guide uses specific terms to convey specific intent. Familiarity with these terms and definitions will facilitate comprehension, will act as a common source of understanding among team members, and will cause the project to flow more easily and efficiently. The following table lists terms that appear throughout this guide.

Important Terms

Term	Definition
Activity	Work that is completed within a specified time period. Activities require human, financial, and time resources.
Customer	Someone who requests products or services. Customers can be within or outside your organization.
Deliverable	Document or outcome that is produced by performing a required activity and is delivered at specified date.
Deployment project	Implementation phase of the project that occurs after all planning elements are complete.
Fixed-release date	A specified date that is established as a release milestone.
Interim milestones	Interim activity-synchronization checkpoints that are used by the project team to assess cumulative and overall progress. These milestones allow the team to build deliverables for major milestones incrementally.
Microsoft Solutions Framework	A collection of methods and processes that can be customized to meet specific technology implementation needs or enterprise requirements. MSF principles are guidelines, not prescriptive methodologies. For more information, refer to https://www.microsoft.com/MSF/.
Microsoft Certified Solution Provider (MCSP)	Companies certified by Microsoft to offer services and solutions built with Microsoft technology. MCSPs can be either members or partners. For more information, refer to https://www.microsoft.com/mcsp.
Milestone	A specified point when the entire project team synchronizes deliverables to enterprise expectations.
Planning model	A flexible, milestone-based process that results in developing a customized project plan.
Service guide	The document you are reading. Service guides include both the main document and its supporting resources.
Planning service	One of many Microsoft offerings designed to help you plan, build, and manage a customized computing systems solution. Microsoft offerings include: Planning services Enterprise Program Manager Microsoft Solutions Framework Premier Support Services Partner Program Manager
Project plan	A fully documented course of action that includes both a comprehensive list of technical and business planning activities and a schedule that documents project progress. Specific sections include: Project initiation Definition Planning Implementation
Service provider	A person or group that delivers planning services. Service providers include Microsoft Consulting Services, Microsoft Certified Solution Providers, and information technology professionals within enterprises.
Total cost of ownership	The complete cost of implementing and maintaining new information technologies, including human, time, and technical (hardware and software) requirements.
User	Anyone using this service guide (for example, customers, end users, and resellers).

File Compatibility

To ensure compatibility with most users of this guide, all files are in Microsoft® Office 97 formats (Microsoft® Word, Microsoft® Excel, Microsoft® PowerPoint®, Microsoft® Project, and Microsoft® Access).

Viewers for specific applications are available at no cost from the main Microsoft Web site (https://www.microsoft.com/office).

Resources

The Resources section includes a wealth of information designed to assist the project team in producing deliverables that are needed to plan an enterprise-wide project. The following table describes the two distinct types of service guide resources.

Types of Resources

Type	Description
Samples	Examples of actual deliverables produced by specific activities. These documents might use fictional company names, but in all other ways are identical to the deliverables that are produced by an actual project team. Sample documents are required reading.
References	Background information, white papers, glossaries, online resources, and other documents or technical materials that provide technical information about the specific technology or project process. This information is not required reading, but it's a good idea to give them at least a cursory review. You can gain insight helpful to the overall project process. Some references are provided as hard copy. References that change frequently have URL pointers to the original.

Online Resources

The text of this guide includes many embedded URLs. Online resources include URL pointers to Microsoft and vendor Web sites that are either directly related to or provide ancillary information to the technology presented in this guide. Background information, product data sheets, and white papers change frequently. Use these URL pointers as a method to stay abreast of new product versions, Microsoft updates, and vendor reviews and tools that are time sensitive.

For a compilation of all online resources referred to throughout this guide, refer to the Master List of Resource Documents and Online Pointers in the last section of this guide.

General Reference Materials and Software Tools

Identifying and obtaining resources, scheduling training classes, and purchasing reference materials are also important tasks. The resources in the following table offer additional Microsoft product and training information.

General Microsoft Reference Materials and Software Tools

Resource	Location
Software needed to build a test environment.	Refer to your Microsoft consultant for application-specific product data sheets.
Microsoft Consulting Services. North American and international field offices.	https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise=portfolio=consulting
Microsoft Solutions Framework. Online information about core Microsoft strategies and solution sets that are used to develop and implement new technology in the enterprise.	https://www.microsoft.com/MSF/
Microsoft Solutions Framework Web site. A comprehensive set of MSF documents online.	https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise=solutions
Microsoft Certified Solution Providers Online. Companies that are certified by Microsoft to offer services and solutions using Microsoft technology.	https://www.microsoft.com/mcsp/
Microsoft Developer Network. Tools and product information about Microsoft technology.	https://www.microsoft.com/msdn/
Microsoft TechNet. Technical information about Microsoft technologies.	https://www.microsoft.com/technet
Microsoft Technical Support—Premier Support and Technical Account Manager (TAM). Basic and enhanced supportability review. Consult your MCS liaison or TAM for additional information.	https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise=consulting=supportservices (Enterprise Services) https://members.microsoft.com/partner/default.aspx Microsoft Sales and Information: (800) 426-9400
Microsoft® BackOffice® Resource Kit. Tools and white papers that assist with application development and management.	https://www.backoffice.microsoft.com/
Channel Training and Certification. Training for network administrators and other development, technical, or engineering professionals.	https://members.microsoft.com/partner/default.aspx
Microsoft Online Support. Updated product information and technical support offerings for all Microsoft products.	https://www.microsoft.com/support/
Microsoft Knowledge Base. Technical information based on 50,000 detailed articles on Microsoft products, bugs, and fix lists; documentation errors and answers to the most commonly asked technical support questions.	https://www.microsoft.com/support
Microsoft Press	https://www.microsoft.com/mspress/

There could be a time lag between the publishing date of this guide and when you actually use it. During that period, some Microsoft URLs might become outdated. For the most current information, refer to the main Microsoft Web page at https://www.microsoft.com/search/.

Vision/Scope Approved Milestone

Overview

Planning the Project

The Vision/Scope Approved Milestone is an opportunity for customers and the team (described below) to agree upon project vision and scope.

In this section, you will learn about the team model and how to design the deployment team and determine the vision and scope for the project, including the project structure and any associated risks. At the attainment of the milestone, you and the team will be prepared to assemble a comprehensive project plan, using the vision/scope document as a guide.

Activities, Resources, and Deliverables

The following table lists planning activities, their resources, and their associated deliverables.

Activity	Resource	Deliverable
Identifying key team members	MSF Reference Guide Click here	Project team
Defining vision and scope	Sample Vision/Scope Document Included in self-extracting file Tsdeploy.exe as Sample Vision-Scope.doc	Vision/scope document
Assessing risk	Sample Risk Assessment Matrix Included in self-extracting file Tsdeploy.exe as Samples\Risk Assessment Matrix.doc	Risk matrix
Defining project structure	Information in text	Project structure document
Approving the vision/scope	Sample Vision/Scope Document Included in self-extracting file Tsdeploy.exe as Sample Vision-Scope.doc	Approved vision/scope

Understanding the Team Model

Identifying Key Team Members

The Microsoft Solutions Framework team model offers an effective approach to creating teams for projects. The model calls for building teams with people who have the right expertise for the job, who are empowered to use their expertise, and who are held accountable for results in their areas of responsibility.

The team model works as a team of peers, with each member filling a well-defined role on the project and working cooperatively with other team members.

Six distinct roles must be filled and are outlined in the table below.

Roles of the Planning and Deploying Team

Team member	Role	Skill set
Product management	Defines deployment vision	Familiarity with Terminal Server Understanding of business drivers
Program management	Drives critical schedule decisions	Microsoft Certified Systems Engineer (MCSE) recommended Familiarity with project management tools like Microsoft Project
Development	Builds or implements product or service	Experience developing in a multi-user environment Familiarity with the rules for writing applications in a Terminal Server environment Familiarity with applications used in the environment
Testing	Ensures all issues are known before deployment Performs scalability analysis and performance testing	Familiarity with applications and operating system Microsoft Certified Systems Engineer (MCSE) recommended
Logistics management	Ensures a smooth rollout of product or service	Familiarity with the organization's system and network infrastructure Good relationship with solution providers and vendors Good understanding of the delivery schedule
User education	Helps identify and meet end-user needs and desires, with such roles as: Technical writer Graphic artist Trainer	Good understanding of Terminal Server and the applications to be used with it Ability to write clear and useful technical documentation Experience training users
Support (in addition to MSF team model)	Provides experts from outside disciplines, such as a: Business analyst, who helps formulate test metrics and analyze results Technical visionary, who offers technical insight to business solutions	Good understanding of Terminal Server and the applications to be used with it

The team should include a mixture of service providers, information technology (IT) and information systems (IS) managers, department sponsors, executive managers, and internal and external specialists. Ideally, these same individuals will also participate in deployment, which will promote project buy-in and maintain continuity throughout deployment.

Planning team responsibilities include:

• Creating the project plan.

• Defining the plan's assumptions and risks.

• Making major decisions that define and implement deployment.

Combining Roles

The six roles identified in the MSF team model should be represented on the project team to help ensure a complete and effective plan, although it isn't always necessary to have a one-to-one relationship for each role. Refer to the MSF Reference Guide (https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise=solutions) for a full description of these roles and how best to combine them.

Defining Vision and Scope

Thinking Expansively

The vision statement is an expansive view of the proposed Terminal Server deployment. It describes the top business reasons for deployment and broadly defines the overall results of successful completion.

The product manager creates the vision statement with input from other team members. The business sponsor, project management, deployment team leader, and other team members should review its content. The business sponsor or upper management has final approval.

For an example of a vision statement, see Sample Vision/Scope Document in the Resources section (Included in self-extracting file Tsdeploy.exe as Sample Vision Scope.doc).

Applying Scope

Scoping defines which portions of a vision can actually be accomplished within project constraints. The project scope provides boundaries for the vision statement by adding specific details that include business reasons for deployment, features, resources, and schedule framework.

Terminal Server allows an organization to deploy new technology more quickly and simply and at a lower cost than might otherwise be possible. Nevertheless, you should realistically assess the issues that bear upon the team's ability to carry out the vision statement and set limits based on those issues to result in a greater satisfaction level and a deployment process that is better able to satisfy the demands placed on it.

The issues that are most significant to scoping fall broadly into four basic categories.

• Budgetary considerations. Deploying Terminal Server will likely require purchasing new software or licensing additional seats, new servers for Terminal Server itself, and any Windows-based terminals or low-end personal computers to replace green screen terminals or non–personal computer hardware for the Terminal Server client. Consider the organization's budget when creating a realistic scope and adjust expectations accordingly.

• Time considerations. Deploying Terminal Server and training users will take time. If a great number of users are moving to the Windows-based environment from mainframe workstations or other non-Windows–based hardware or are otherwise unfamiliar with the Windows interface, you must allot more time to training. Make note of any factors that would require deployment by a certain time. If circumstances dictate a more rapid deployment than is reasonable, consider a smaller deployment to meet a deadline with a more complete deployment to follow, or consider initially implementing fewer functions or applications.

• Integration considerations. How will Terminal Server integrate with current hardware and software? Will users of the Terminal Server client continue to require access to software on their local personal computers, requiring them to retain their existing hardware? Will Terminal Server need to communicate or exchange data with databases or other systems?

• Human resource considerations. How many people will be required for the deployment efforts? Will any of them be involved in other projects that take precedence over yours? Consider how many work-hours will be lost to training users on the Windows NT environment and on new and unfamiliar application software. If this number is too high, you may want to scale back the vision or perform the deployment in stages. In deployment scenarios with multiple phases, consider assembling subteams to deal with specific issues for each phase.

Creating the Scope

The scoping process should be S-M-A-R-T: Specific, Measurable, Achievable, Results-based, and Time-oriented. The accompanying table offers a more detailed definition of S-M-A-R-T.

S-M-A-R-T Definitions

Action	Definition
Specific	Specifying results to be achieved (for example, what action will be taken or what application will be deployed).
Measurable	Clearly specifying what will be achieved (for example, the number of seats deployed or the number of business units completed).
Achievable	Identifying what the enterprise will achieve by this action (for example, increased interoperability).
Results-based	Establishing realistic outcomes based on company resources and project parameters.
Time-oriented	Setting a realistic time frame to achieve specific goals (for example, will commence on X date and complete on Y date).

If a vision statement articulates the ultimate goals of a project, then the project scope defines its limits while looking at ways to reach the goals.

Important steps in defining those limits and spelling out those goals are:

• Stating the problem, or describing the current situation. You need to know what you already have before you can decide how it must be changed. Inventory your overall infrastructure for current problems or issues that Terminal Server will address. During the next phase, you will go into this in much greater detail. For scoping, look at known problems and any previous attempts to address them, if applicable.

• Identifying business drivers and constraints. Consider the business drivers listed in the "Project Overview" section and determine which, if any, apply to the current situation. Identify any other business drivers or total-cost-of-ownership issues that apply to your situation.

• Using names and numbers. To be useful, business objectives should be specific and measurable; use names and hard numbers when possible.

  Rent-a-Car, Inc., would like to reduce maintenance and support costs by replacing 1,500 green screen terminals at its headquarters in Atlanta with Windows-based terminals running the Terminal Server client.

• Stating assumptions. It's a good idea to include a list of project assumptions, constraints, dependencies, and anything else that is required or assumed necessary for successful deployment.

If the team performs a careful review of these issues up front, they will discover errors in assumptions early, before the actual deployment. Errors discovered during the pilot, controlled introduction, or actual deployment could cause significant and costly delays in enterprise-wide implementation.

Assessing Risk

Describing the Process

Dynamic, competitive, and ongoing risk management is a core MSF principle. Accomplishing this requires a good communication process and an environment in which people feel free to identify risks and are willing to express tentative or controversial views.

Possible risks in deploying Terminal Server include:

• Lacking knowledge and understanding of Windows NT.

• Not testing sufficiently, or not allotting enough time for testing.

• Failing to sufficiently document the current environment before beginning deployment.

• Failing to fully account for the behavior of current applications in a Terminal Server environment.

• Failing to accurately determine the scalability of current or future applications.

• Failing to adequately train or recruit administration personnel to work with multi-user systems.

Rent-a-Car, Inc., uses a custom Visual Basic accounting program that stores user-specific information in the root directory of the user's hard disk drive. In a multi-user environment like Terminal Server, this would cause each user's preferences to be overwritten by the next user who launches the application. Without a good risk management plan, this problem would have been discovered late in the process, resulting in lost time and money. The team's risk management plan enabled them to identify the problem during the planning stage and arrange for the program to be revised.

Identifying and Ranking the Risks

Risk identification and ranking is the first step in the proactive risk management process. It provides the project team with the information it needs to bring major risks to the surface before they adversely affect the project.

As they discover a risk, team members should develop a risk statement and enter it on a master list of risks, describing whether the risk should be considered a high, medium, or low risk.

For a risk to be managed, it must be expressed clearly, with consideration for not only a symptom but also a result. So, a properly expressed risk statement considers what is causing the situation to arise (that is, the condition) and the expected result (that is, the consequence).

For more information on risk identification and assessment, see Sample Risk Assessment Matrix in the Resources Included in self-extracting file Tsdeploy.exe as Sample Risk Assessment Matrix.doc).

Analyzing Risks

Risk analysis is the conversion of risk identification and ranking into risk decision-making information. Analysis ensures that the team will be working on the right risks.

Risk is composed of two factors: risk probability and risk impact. Risk probability is the likelihood that an event will actually occur. Risk impact is the severity of adverse effects, or the magnitude of a loss, if the risk occurs. Sometimes a high-probability risk has low impact and can be safely ignored. Sometimes a high-impact risk has low probability and can be safely ignored as well. The risks that have high exposure (high probability and high impact) are the ones worth managing. Reducing either the risk probability or the risk impact can achieve this goal.

Risk analysis weighs the threat of each risk to help decide which risks merit taking action. Managing risk takes time and effort away from other parts of the project, so it is important to do only what is absolutely necessary to manage them. The key is to identify a limited number of major risks that must be managed (usually 10 or less).

For an example of how risks can be assessed, see Sample Risk Assessment Matrix in the Resources section (Included in self-extracting file Tsdeploy.exe as Sample Risk Assessment Matrix.doc).

Defining Project Structure

Assigning Team Roles and Responsibilities

The complexity of a large-scale deployment of Terminal Server makes it advisable to divide project tasks by functional areas, as in the following:

• Engineering

• Technical support

• Operations

• Training

• Program management

• Rollout

Accordingly, you should assemble project subteams along the same lines. This approach enables:

• The program manager to arrange team members into appropriate groups and to divide the work into packets relating to each functional area.

• The project team members to complete the work in parallel and focus on their areas of expertise.

Communicating Progress

The team should communicate the progress of the project to the business sponsor and to the organization's IT structure at large. With this information, management can begin deployment preparations and establish appropriate expectations of how Terminal Server will change their server operations. Users are typically interested in:

• When the new system will reach them.

• How much disruption they will undergo (collectively and individually).

A communications plan requires such details as:

• Communication type (for example, Microsoft PowerPoint presentation, e-mail, newsgroups, or Microsoft® NetMeeting session).

• Audiences for each type of communication.

• Frequency with which each type of communication will be updated and distributed.

Approving the Vision/Scope

Assembling the Vision/Scope Document

The vision/scope document is the first written commitment made to the planning team, executive sponsors, and IT management. It should:

• Define the enterprise's vision for deploying Terminal Server and the perceived benefits of the deployment.

• Offer specific goals.

• Define overall deployment planning objectives.

• Provide information for developing the logical design.

Specifically, it should pull together:

• A vision statement document.

• A scoping document.

• A risk assessment document that identifies technological and organizational issues that might affect progress on the project.

• A project structure document, including a project schedule, which describes the administrative structure for the project team.

For an example of a completed vision/scope document, see Sample Vision/Scope Document in the Resources section (Included in self-extracting file Tsdeploy.exe as Sample Vision-Scope.doc).

Gaining Approval of the Vision/Scope Document

Gaining approval of vision/scope marks the first important milestone in the overall planning process. It signifies upper management approval of the overall direction and scope of the project.

Before presenting the document, the project team should identify and handle any major considerations or enterprise policy issues. It should also approve other issues, such as company-specific wording or expressions of company policy.

It's important that the team buy in to the final document that it is offering to senior management for approval. After senior management gives final buyoff authority to the vision/scope document, the team should archive it and use it as a baseline.

For an example of a vision/scope approval meeting agenda, see Sample Agenda for Vision/Scope Approval Meeting in the Resources Included in self-extracting file Tsdeploy.exe as Sample Agenda.doc).

Project Plan Approved Milestone

Overview

Understanding Planning

Planning is the process that customers and team members use to move from a shared vision of what they want to build into making decisions about how they will build it. Planning culminates in the Project Plan Approved Milestone.

The Project Plan Approved Milestone offers an important opportunity for the team to reassess risk, establish priorities, and finalize estimates for schedule and resources.

Activities, Resources, and Deliverables

The following table lists planning activities, their resources, and their associated deliverables.

Activity	Resource	Deliverable
Documenting the environment	Sample Environment Analysis Included in self-extracting file Tsdeploy.exe as Sample Environment Assessment.doc	Current environment analysis
Creating a functional specification	Microsoft Solutions Foundation Web site https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise=solutions	Functional specification
Creating/approving the logical design	Sample Logical Design Included in self-extracting file Tsdeploy.exe as Sample Logical Design.doc	Logical design
Creating/approving the physical design	Sample Physical Design Included in self-extracting file Tsdeploy.exe as Sample Physical Design.doc	Physical design
Reviewing the risk assessment	Sample Risk Assessment Matrix Included in self-extracting file Tsdeploy.exe as Sample Risk Assessment Matrix.doc	Risk assessment matrix
Building the master project plan	Microsoft Solutions Foundation Web site https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise=solutions	Master project plan document
Approving the master project plan	Microsoft Solutions Foundation Web site https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise=solutions	Approved project plan

Documenting the Environment

Taking Stock of What You Have

Before beginning a deployment of any new technology, it's always a good idea to survey the existing infrastructure to help you determine how the new components will fit in.

This step is especially important with Terminal Server deployments. It is vital that you enter the process with a good understanding of the computing and networking environment in which you will be working. To gain this understanding, you must complete a thorough assessment that takes into account not only the technical infrastructure of the deployment environment but also its business and organizational structure.

To see a typical environment assessment, refer to Sample Environment Assessment in the Resources section (Included in self-extracting file Tsdeploy.exe as Sample Environment Assessment.doc).

The first part of your assessment should be a brief treatment of the nature of the business or organization and how it is structured.

Rent-a-Car, Inc. (RACI) provides rental cars to vacationers and leisure renters throughout North America and at various locations in Europe and South America. RACI manages the information systems of its worldwide reservation centers from its headquarters in Atlanta, Georgia, where its reservations mainframe is located.

If deployment will affect different divisions, describe them and how they relate to one another and to the organization as a whole. Consider providing an organizational chart, if one is available or can be constructed, to show how different divisions and individuals interconnect. Provide the names and/or titles of the individuals involved in deployment and decision-making.

The consulting team will be assisting RACI's director of information systems, who reports to the chief information officer (CIO). The CIO is responsible for budgeting and procurement for the Terminal Server deployment project.

Documenting Technical Information

By documenting the existing technical environment, the deployment team can make more educated decisions about issues such as the following:

• Installing and configuring Terminal Server.

• Choosing the appropriate hardware.

• Creating a set of concise configuration parameters for application deployment.

• Resolving any architectural design considerations.

Documenting LAN Information

You should thoroughly describe the makeup and structure of the local area network (LAN). Understanding the LAN will help you determine if sufficient bandwidth and wiring are available to support all the users who will be making connections to Terminal Server. It will also help you spot any wiring or structural improvements you will need to make to bring connectivity to users of legacy terminals who cannot currently connect to Windows-based systems. You should:

• Document the physical aspects of the LAN. Is it a TokenRing or Ethernet network? Does it use switches?

• Document the protocols used to move data through the network, such as TCP/IP, Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX), and NetBIOS extended user interface (NetBEUI). This data is important in determining if Terminal Server clients will be able to connect to the servers, and how.

Documenting WAN Information

If the organization connects geographically separate sites with a wide area network (WAN), it is important to determine if the available bandwidth can support the demands that applications, including Terminal Server, will place on it. Document the speed of the links and the presence or absence of any backup links or redundant paths. If the WAN consists of frame relay connections, distinguish between committed rates and burst rates.

• Provide a diagram of the WAN showing its topology and the pieces used to connect it together.

• Document the types of routers used and their vendors, like 3Com or Cisco. Is the hardware up to date, and does it run the most up-to-date software available for it? Additionally, if DHCP is not presently in place and you are planning to deploy it as part of the Terminal Server project, you must determine whether the router software properly deals with DHCP frames and whether the BootP ports have been enabled to allow the DHCP frames to pass through the network.

• Determine if filters have been implemented on the routers or firewalls that would prevent clients from remotely gaining access to Terminal Server. Check to make sure that the RDP port (port 3389) is not blocked at the firewall and that access to specific corporate segments is not limited to certain Internet Protocol (IP) or Internetwork Packet Exchange (IPX) network addresses. If these blocks are in place and they prevent remote connections, the team must address them during deployment.

Documenting Network Services

Document the network protocols used within the organization.

• Document the Windows Internet Name Service (WINS) infrastructure. Note the number of servers handling WINS and their names. This information will help you determine where and how the servers running Terminal Server must register with the network. This information will help you configure the primary and backup WINS servers that the Terminal Server computers will use for registration and name query. Registration helps the user locate the server's address, and name query allows Terminal Server to access data on other servers.

• Document the network's use of dynamic host configuration protocol (DHCP), if any. Make note of which users have statically assigned IP addresses and which users use DHCP. Document the lease intervals and scope assignments. Document all global settings (such as DNS Service identity), scope settings (such as default gateway), and other settings that form the complete DHCPOFFER packet. Some Windows-based terminal vendors do not provide a mechanism to store the DHCP information in flash read only memory (ROM), which may require the use of additional addresses.

• Document the Domain Name System (DNS). Note the namespace for the domain in which Terminal Server will operate. Where should new servers and clients register? For what domains and DNS Services does the server need to be configured? If the organization makes use of round-robin DNS for load balancing, do the servers conform to RFC 1794?

• If the infrastructure provides for dial-up use, make note of the service used, such as Virtual Private Networking or Windows NT Remote Access. What is the maximum connect speed for dial-up users?

• Users can gain access to Terminal Server over the Internet. You may want to provide customers or suppliers with access to applications or data. Or you may determine that the Internet is the easiest way for company end users to gain access to Terminal Server. If you plan to make servers available over the Internet, consider the security implications.

  If the organization uses a firewall, determine if it is a packet-level or application-level firewall. Packet-level firewalls are easier to configure for new protocols. If the organization uses an application-level firewall, check to see if the vendor has defined a filter for the Remote Desktop Protocol (RDP); if not, you should contact the vendor and ask them to create a filter.

  Document the method the network uses to connect to the Internet. This will help you determine how much bandwidth is available to Terminal Server. Does the network have a permanent connection? Describe the number and types of lines used to make the connection, such as T1 or ISDN.

Documenting Server Information

Document the server environment and any organizational standards that apply to servers.

• Document the network operating system. Does the network environment use Windows NT or Novell NetWare software? If NetWare, document the frame types, protocol, and physical topology. If Windows NT, document protocol and physical topology.

• Document any server monitoring tools currently in use, such as HP OpenView or NetIQ. What tools, if any, are being used for capacity planning?

• Document the backup system. Note the software used for backing up computers on the network, like Seagate Arcada or Cheyenne ArcServe. We strongly recommend that you have procedures in place for backing up Windows NT registries, file permissions, and files before deploying Terminal Server. Document any existing processes for offsite backup and disaster recovery.

• Document the protocols used to make client/server connections. Try to determine if the organization has any long-term plans for protocol use that would necessitate a change from the current environment.

  

  Terminal Server supports only TCP/IP connections between the Terminal Server client and server. If any other protocols are in use, such as IPX or NetBEUI, you must add TCP/IP. You will still be able to use IPX or NetBEUI as the transport protocol for non–Terminal Server traffic, such as network file or printer sharing, or between the client portion of a client/server application and its server.

• Document any hardware standards currently being used. What kinds of servers are in place or are being purchased? If existing servers will be used to run Terminal Server, is the server infrastructure scalable? How much RAM does the typical server have, and can it be expanded? Verify that all server equipment is on the Windows NT Server 4.0 Hardware Compatibility List, included with the Terminal Server software and available online at https://www.microsoft.com/windows2000/server/howtobuy/upgrading/compat/default.asp.

• Reproduce and annotate any logon scripts. Must the logon scripts be modified to be more compatible with Terminal Server?

Documenting Client Information

These questions refer to the hardware currently sitting on users' desktops, including personal computers, green screen terminals, and non–personal computer desktop devices such as Macintosh computers, UNIX workstations, X terminals, and others. This should be a fairly high-level assessment of the current environment. Record raw numbers and division- or organization-wide standards, rather than attempting to document individual desktops.

• Give an overview of the organization, noting the total number of workstations currently in use.

• Describe the current configuration of the computers that will be running the Terminal Server client in terms of CPU, operating system, available hard disk space, RAM, and video. Again, it's not necessary at this point to document the environment on the level of the individual workstation. Record any official or unofficial standards that may exist by division or throughout the organization, and make note of any computers that fall below the standard.

  

  Terminal Server Client requires at least a 386/33 CPU and 8 MB of RAM running Windows for Workgroups 3.11 or later with the Microsoft TCP/IP-32 3.11b stack (included on the Terminal Server CD-ROM) or later. The client takes up about 500 KB of hard disk space and requires a video graphics adapter (VGA)-compatible video card. Any client workstations not meeting this standard must be upgraded or replaced. Document any computers within the organization that do not meet the minimum configuration.

• Document the presence of any terminals in the environment relevant to the Terminal Server deployment, including any existing Windows-based terminals that will be used with Terminal Server and any green screen (typically 3270, 5250, or VT-100 terminals) or UNIX X terminals that will have to be replaced. Document what kind of terminals they are and how many.

  Green screen terminals cannot be used as Terminal Server clients, but in most cases you will be able to use terminal emulator software to gain access to software on existing mainframes and hosts. Some Windows-based terminals currently on the market support only the Independent Computing Architecture (ICA) protocol for Terminal Server–type connections. To connect these devices to Terminal Server using ICA only, you must use Citrix Systems MetaFrame add-on software to add support for the ICA protocol to Terminal Server. In addition, some of these terminals can be flash upgraded to use RDP, reducing the need for MetaFrame. Check with the terminal vendor for more information. For more information about MetaFrame, visit the Citrix Web site at https://www.citrix.com.

• Document any non-Windows systems with which Terminal Server clients must interface. If current workstations gain access to these systems through a non–Windows NT gateway, you may need to install a new gateway. Determine whether the organization has appropriate licenses for any Telnet, 3270, and 5250 software needed to gain access to these systems from a Windows NT environment. If Terminal Server will be used to gain access to a system running network file system (NFS), does the organization have the appropriate software to allow the connection?

Documenting Applications

Document the applications you intend to deploy to client desktops with Terminal Server. Some applications have features that prevent them from working with Terminal Server or cause them to perform poorly, and you may want to instruct users to install these applications locally where feasible.

The white paper Optimizing Applications for Windows NT Server 4.0, Terminal Server Edition in the Resources section (Included in self-extracting file Tsdeploy.exe as Optimizing Applications.doc) contains important information on using applications with Terminal Server. Visit https://www.microsoft.com/ntserver/ for the latest information on optimizing applications for Terminal Server.

• Use the Application Assessment Profile in the Resources section (Included in self-extracting file Tsdeploy.exe as Application Assessment.doc) to survey each application for problems that may inhibit or prevent effective implementation.

• Document any applications that require special hardware to operate, like barcode scanners or card swipes. You can use these devices with a Terminal Server client only if they connect to the personal computer or terminal in such a way that the computer recognizes the peripheral as a keyboard-type device. Peripherals that connect to the local computer through the parallel or serial port or through a special card are not currently recognized by the RDP-based Terminal Server client, but may be available using the ICA protocol.

• Document any custom applications that will be deployed on servers running Terminal Server and whether the organization possesses the source code. Some custom applications may need to be modified to run in the Terminal Server environment. Consult the Optimizing Applications for Windows NT Server 4.0, Terminal Server Edition white paper cited earlier for help with modifying custom applications to conform to core practices.

• Document any applications that use the Distributed Component Object Model (Distributed COM) to distribute objects across the network, and make note of which Distributed COM activation models they use.

Terminal Server supports only the anonymous activation model. See Following Best Practices in the "Project Plan Approved Milestone" section for more information.

Documenting Other Server-based Applications

Document the server-based applications you intend to run under Terminal Server. Some server-based applications may require additional configuration to run under Terminal Server. Here you need only be concerned with the server-based applications you intend to use with Terminal Server, not applications running on other Windows NT servers throughout the environment.

Although Terminal Server is part of the Windows NT Server family, it has been tuned to run desktop applications, including presentation services. In several respects, such as with the thread-scheduling model, Terminal Server more closely resembles Windows NT Workstation. For this reason, you should avoid deploying server-based applications on Terminal Server, such as those contained in the Microsoft BackOffice Suite because of the resource requirements for these applications. Some server-based applications may not work at all, and you may experience significant performance degradation with others.

Try deploying server-based applications to other Windows NT servers if possible, and be sure to plan adequate testing of any applications that must run on Terminal Server so that you can address any performance issues during the testing and piloting processes. Visit https://www.microsoft.com/ntserver/ for more information on writing and deploying applications in a Terminal Server environment, or contact the application vendor for compatibility information.

Although Microsoft does not recommend installing BackOffice applications on Terminal Server, users can gain access to BackOffice applications on other Windows NT Server computers from client applications on Terminal Server. You should document the BackOffice applications and other server-based applications to which users will gain access from client applications on Terminal Server.

• Will you use a Microsoft® SNA Server as a gateway to an IBM mainframe? What version of SNA Server will you be using? How many users must it support?

• Will you use a proxy server, such as Microsoft® Proxy Server? If so, does it support Winsock? How many users must the proxy server support?

• Will you run Microsoft® Internet Information Services? How many concurrent users must it support?

• Will you host a Microsoft® SQL Server™? How large will the database be? How many concurrent users must you support? What will the performance requirements be?

Documenting Naming Conventions

Document any naming conventions in use throughout the environment. List any domain names currently being used throughout the organization, and make note of any conventions governing their assignment and use. If the organization already has a Windows NT Server domain plan in place, document any naming conventions associated with it. Also document any conventions used in assigning:

• Server names

• Workstation names

• Logon IDs

• Printer names

Documenting Support Services

Document the mechanisms that support the hardware, software, and users.

• Describe the security and administration services. Will Terminal Server deployment affect any sites outside the United States? Export restrictions on strong encryption could effect your security plans for Terminal Server.

  Also, document any password policies currently in place. How often are passwords set to expire? Is there a minimum or maximum password length? Does the system automatically reject impermissible passwords (for example, words found in the dictionary)?

• Does the organization have a regularly staffed help desk? If so, what are the hours of operation? What systems are in place for monitoring help desk calls? Does the organization keep a technical support Web site available to its users?

• How are administrators and end users trained on applications and operating systems? Has the organization made plans for Terminal Server support and training? Support personnel with previous experience in a multi-user environment may be able to leverage their skills to help support Terminal Server.

• What support contracts does the organization have with Microsoft and other vendors? Are there any additional commitments from vendors regarding mission-critical applications?

• Does the organization have any service-level agreements, guaranteeing service within a certain period of time after problems are detected? Describe any service-level agreements in moderate detail. Does the organization use multiple servers to keep mission-critical applications running?

Creating a Functional Specification

Explaining the New Process

Creating a functional specification is the next step after documenting the environment. The resulting document, which is written and owned by the program manager, is a high-level explanation of how a product, system, or process will be designed and what it will do.

A functional specification should be simple and straightforward, so that executives and members of groups outside the project team who read it can get a quick understanding of what the product, system, or process does.

It should be fairly detailed, so that members of the project team can use information from it to complete the deployment. That means it should contain such things as the vision/scope document, a statement of issues/problems, and design information.

Signing Off on the Functional Specification

The functional specification should be considered a blueprint for the deployment process that presents the goals and design in concrete form.

Although the functional specification is not a milestone, it is one of the major deliverables during planning, and it represents a significant step along the road toward reaching the Project Plan Approved Milestone.

Its approval and signoff by the members of the project team should be fairly formal. Each member of the team should take a careful look at the document, especially those portions that make promises about functions and capabilities for the new process and that set schedules and timetables, to make certain that what is being outlined matches their understanding of what can be delivered.

However, as important as it is, the team should not treat the functional specification as something that has been written in stone. It should be a living document that the team updates regularly to reflect any changes in scope or schedule.

Creating and Approving the Logical Design

Understanding Logical Design

Although this guide contains specific information on project design in the logical and physical design phases, you should not think of the design process as being composed of discrete modules that have little to do with each other. Instead, think of the process as a continuum, with periodic stages in which you baseline your current thoughts on the design and put them on paper for others to comment on and refer to. Creating the logical design is the first of those phases.

Logical design helps you understand and express the demands, drivers, and business activities that a solution will satisfy. Before you embark on a large-scale project like deploying Terminal Server, you should first describe how the deployment project meets the requirements that have been identified by the organization and how the basic business activities of the user might be affected. Failure to make this explicit may result in a poorly designed solution that is inadequate to meet the demands placed on it, resulting in lost time and money.

Defining Objectives

The first part of designing logically is to identify the business drivers that have most influenced the decision to deploy Terminal Server. Refer to Determining Business Drivers in the "Project Overview" section for a list of drivers that Terminal Server is typically deployed to satisfy. Consider which of these drivers are relevant to the current organizational environment. You may want to add business drivers of your own.

State these drivers as goals to be met. Describe the goals in terms specific to Terminal Server and to the situation in which you are working. For example, if your goal is to provide remote access to Windows-based applications, describe the users who need remote access and the kind of work they will be performing.

Addressing Objectives

After you have identified your goals, describe how deploying Terminal Server will meet them. Your description should cover all the major areas of concern to the organization, but be high-level enough to convey project vision without bogging down in technical details. The purpose of the conceptual design document is to give everyone involved an overview of the entire project and how it will meet its goals. By keeping the document concise, focused, and at a high level, you will prepare the project team for the more detailed planning that is to follow.

For an example of a logical design, see Sample Logical Design in the Resources section (Included in self-extracting file Tsdeploy.exe as Sample Logical Design.doc).

Creating and Approving the Physical Design

Understanding Physical Design

The physical design is the part of the design process in which you collect the information you have gathered about the current state and the goals that have been identified and use this information to develop a plan for implementing Terminal Server within the limits set forth in the vision/scope document.

The physical design builds upon the logical design by applying the real-world technology constraints, including any implementation and performance considerations. This is also the point at which you can estimate real resources, costs, and schedules.

For an example of a physical design, see Sample Physical Design in the Resources section (Included in self-extracting file Tsdeploy.exe as Sample Physical Design.doc).

Considering Domain Structure

The first part of developing the physical design involves planning the position of Terminal Server within a Windows NT Server domain.

It's important to remember that no single domain design should be considered "correct." Every organization will have a different architecture to accommodate different needs and limitations, and you must plan the Terminal Server deployment accordingly. However, you should keep in mind a few rules when planning to implement a Terminal Server solution:

• Terminal Server need not be in a Windows NT Server domain to function, but without a domain architecture, users must have separate accounts on every computer running Terminal Server. This limits scalability and makes it more difficult to administer groups of users. If the organization does not currently use Windows NT Server domains, you may want to set up one or more domains for Terminal Server and the users and workstations that will be connecting to servers running Terminal Server. This is especially true if the organization eventually plans to scale Terminal Server to accommodate more users. Consult your Windows NT documentation for more information on setting up Windows NT Server domains.

• Administrators can choose to add attributes that are specific to Terminal Server to user accounts. This adds a small amount of information, typically 1 KB or less, to each user's entry in the domain's Security Accounts Manager (SAM) database. This additional information is not necessary, but it allows the administrator to exercise additional control over individual user settings.

  Consider the implications of adding these attributes to individual user accounts. In a small domain or in a domain in which few users will be using Terminal Server, the overall effect on the SAM size will probably be negligible. In a domain with a large number of Terminal Server users, however, this can cause the SAM to grow at a greater rate than it otherwise would. Take care when deploying Terminal Server to ensure that the setup you choose does not result in SAMs that are too large. See Reducing SAM Size in this section for some tips on accomplishing this.

  

• Every Windows NT Server domain has at least one server that functions as a domain controller. We strongly recommend that you not run Terminal Server on any computer that is also a domain controller because of the resource load that Terminal Server places on the system. Also, because Terminal Server is designed to perform like Windows NT Workstation at the end-user level, the system will not assign top priority to critical domain-level processes such as user account replication, logon requests, logon script replication, and authentication requests. In addition, domain controllers cannot be cloned because the security identifiers (SIDs) will be duplicated across the cloned servers and will therefore be unable to join the domain.

  An exception might be a company with no preexisting Windows NT Server domains that requires only a few servers running Terminal Server. If this company wants to use global groups to apply user policies and to create user accounts that can be used across multiple servers, it might be appropriate to install a server running Terminal Server as a domain controller rather than as a member server.

  Likewise, if the organization must provide outside users with access to its network using Remote Access Service (RAS), consider putting the RAS server on a different computer than the one running Terminal Server. Requiring a server running Terminal Server to authenticate incoming users can lead to performance degradation.

Choosing a Domain Setup

Whether you should put Terminal Server computers into existing domains or create a new domain for them depends on many factors, including the nature of your current domain architecture if one exists, the nature of your WAN implementation if one exists, the number of users in the organization, and the number of users expected to use Terminal Server.

Small organizations without many users typically use a single domain.

Single domain model

The preceding illustration shows all servers and workstations within the organization as members of the same Windows NT Server domain. All server running Terminal Server are deployed as member servers within the domain, and one or more separate servers are used as domain controllers and file and print servers.

Although this setup simplifies and centralizes domain administration, it does not scale very well within large organizations of 15,000 users or more. In addition, the SAM size can grow very quickly if administrators add attributes specific to Terminal Server to users' accounts, which can negatively impact performance.

Even if the organization already uses a single domain model, you may want to move to multiple domains when Terminal Server is deployed. Think about users within the organization who are currently using green screen terminals, Macintosh computers, or other non–Windows-based systems who will be transitioned to personal computers or Windows-based terminals when Terminal Server is in place or who will use clients based on other display protocols such as Independent Computing Architecture (ICA) or x.11 to connect to Terminal Server from their existing hardware. These users probably do not have existing accounts in the Windows NT Server domain, but may need to be added if they are to use Terminal Server. Keep these future users in mind when calculating the SAM size and choosing a domain structure.

If the planned SAM size of the user account domain will exceed 40 to 50 MB, you should consider a multiple domain model or create a separate domain to house the servers running Terminal Server.

Single master domain model

In the preceding illustration, all user accounts are kept in the master domain and individual domains with one-way trust to the user account domain are used for resources like databases and mail servers or for workstations.

Very large organizations often use a variation on this structure with multiple master domains for user accounts.

Multiple master domain model

As shown in the preceding illustration, user accounts are created in one of two or more master domains that can have two-way trust between them, while the resource domains have one-way trust to all master domains but not between each other. If the organization will be providing external users with access to Terminal Server, independent Terminal Server–only accounts can be created in the Terminal Server domain to provide an extra level of security.

Servers running Terminal Server can reside in any of these domains. If SAM size is a concern, you can deploy all servers running Terminal Server into a dedicated resource domain with its own domain controller and SAM. Users who want to gain access to Terminal Server computers should obtain independent user accounts in the Terminal Server domain. This way, the master domain SAM doesn't grow to accommodate any extra Terminal Server attributes included in user accounts.

One disadvantage of this approach is that passwords and other user attributes are not synchronized across domains. A user with accounts in both the master domain and the Terminal Server domain must change both passwords separately. Keep this in mind when training users on Terminal Server in a multidomain environment.

Another option is using a predefined Windows NT logon name and password to give multiple users access to the servers running Terminal Server. This is feasible in situations where Terminal Server is used for task work, such as database entry, or the application has its own security mechanism.

Additionally, you can store password information on the client side and secure it against user modification. Windows-based terminals can be configured to store a username and password in ROM. Other clients can store username and password in the registry or in an .ini file.

These options prevent network administrators from enforcing basic security, so consider the situation carefully before implementing them.

Reducing SAM Size

The Security Accounts Manager (SAM) is the portion of the Windows NT Server registry that stores user account information and group membership.

Although the exact size of any given SAM will depend on a number of factors, you can use the Domain Calculation Model spreadsheet in the Resources section (Included in self-extracting file Tsdeploy.exe as Domain Calculation Model.xls) to estimate the size of the SAM and the replication traffic in a domain you are planning.

Administrators can configure individual user Terminal Server settings by adding attributes such as timeout settings, session reconnect information, and home directory location to user profiles. These Terminal Server–specific settings are not used with other versions of Windows NT, and when used, they add a small amount of additional information to the SAM. Adding attributes to many user accounts can cause the SAM to grow significantly.

The SAM in Windows NT 4.0 is limited to the amount of non-swappable RAM available on the system, so as a general rule you should limit its size to less than 40 MB. Whether you are running Terminal Server within a single domain environment or within a dedicated domain in a multiple domain environment, you may want to take steps to minimize the effect Terminal Server can have on the existing SAM.

Several steps you can take to do this include setting connection attributes server-wide, using regular Windows NT user profiles or roaming profiles, using home directories, using system policies, changing the logon process, or editing user-specific information.

Setting Connection Attributes Server-wide

Because the SAM size increases only when you add attributes to individual user accounts with User Manager for Domains, consider using the Connection Configuration Tool to set attributes like timeout settings, security level, whether to reconnect to a broken session when a user logs back on, and printer connections. The settings you change with the Connection Configuration Tool will apply to all users of the server running Terminal Server to which changes are being made.

Using Regular Windows NT User Profiles or Roaming Profiles

A profile describes the Windows NT configuration for a specific user, including the user's environment and preference settings. Profiles typically contain such user-specific information as installed applications, desktop icons, color options, and so forth.

In some cases, users may have already been assigned Windows NT profiles. It may be desirable to assign Terminal Server–specific profiles to users whenever the user gains access to Terminal Server across the WAN or if the administrator wants to present a session to the user that is different from the user's own desktop.

Whenever a user logs on to a server running Terminal Server, the server will first search for the Terminal Server–specific profile. If Terminal Server cannot locate this profile, it will attempt to load the user's Windows NT profile. This may not be an ideal solution for users who gain access to Terminal Server over a slow WAN link because the Windows NT profile must be transferred across the slow link when the user logs on.

Roaming profiles allow the user to move between different computers and maintain the same environment and preference settings. When a user logs on to Terminal Server, the system checks for the presence of a Terminal Server–specific roaming profile. If one is not found, it uses the Windows NT roaming profile instead.

There are two types of roaming profiles, mandatory and personal. A roaming mandatory user profile is a preconfigured user profile that the user cannot change. One mandatory profile can be assigned to many users. By changing one profile, the administrator can change several desktop environments. You should use this type of profile to assign common settings for all users who require identical desktop configurations.

A roaming personal user profile is a user profile that a user can change. This means that when the user logs off, the user profile is updated to include any changes the user made. When the same user logs on again, the profile is loaded as it was last saved.

Using Terminal Server–specific profiles will add to the size of the SAM. If this is a concern, consider using Windows NT profiles for both Terminal Server and the Windows NT network.

For more information on using roaming profiles, refer to Policies vs. Profiles in the Resources section (Included in self-extracting file Tsdeploy.exe as Policies vs Profiles.doc) and to the Microsoft Windows NT Microsoft Knowledge Base articles 146050, Modifying Ntuser.dat Hive so New Users Get Defined Settings (Included in self-extracting file Tsdeploy.exe as 146050 - Defined Settings.doc), and 168475, How to Create a Base Profile for All Users (Included in self-extracting file Tsdeploy.exe as Base Profile.doc), both in the Resources section. To learn how to create mandatory profiles, see Knowledge Base article 168476, How to Create NT 4.0 Mandatory Profiles, in the Resources section (Included in self-extracting file Tsdeploy.exe as 168476 - Mandatory Profiles.doc).

Unless you manage user profiles correctly, they will tend to grow in size. You might need to use mandatory profiles for the Terminal Server environment or consider using a utility like Microsoft ProQuota, included in Windows NT 4.0 Service Pack 4, to manage the size of the user profiles. In addition, because user profiles are cached each time a user logs on to the server running Terminal Server, you must delete them after the users log off. Note that you cannot use regular Microsoft Windows NT service packs with Terminal Server, so you must obtain Service Pack 4 separately.

For information on deleting cached profiles, refer to Microsoft Knowledge Base article 173870, How to Delete Cached Profiles, in the Resources section (Included in self-extracting file Tsdeploy.exe as 173870 - Deleting Cached Profiles.doc).

To facilitate the use of user profiles, plan ahead and identify where they will be stored and how they can be managed. First, identify a location or locations on a file or print server that have enough space to store the profiles and are readily available to Terminal Server users. Second, create a Windows NT share that users can gain access to with read/write privileges. We suggest that you hide this share so users cannot easily gain access to it. To hide the share, append the "$" symbol to the end of the share name, as in "Profiles$". Note that profiles should be stored in a different location from user home directories.

Using Home Directories

It is critical that you plan to use home directories in a Terminal Server environment because most applications must install user-specific information or copy configuration files for every user. To keep user profiles to a reasonable size (less than 1 MB), we recommend that all Terminal Server users have a network home directory in which application-specific information will be stored.

By default, Windows NT defines a home directory for each user. The default location is the user's profile directory, located under %systemroot%\profiles\%username%. The home directory is called Windows and contains a necessary subdirectory called System. Windows NT writes user-specific application files, such as .ini files, to the user's Windows directory and by default refers any application seeking the system Windows directory to the user's Windows directory.

Users typically use their home directories to save their personal files. This can be a problem if roaming profiles are used and the home directory is located within the user's profile directory because Windows NT copies everything in the user's profile directory to the profile cache each time the user logs on. This can take considerable time and resources, especially if the roaming profile is stored across the network.

Therefore, we recommend that you use User Manager to specify a new location for home directories. One approach would be to create a directory on the file server called Homedirs and give Change permissions to Everyone. Then use User Manager to specify the home directory location as C:\Homedirs\%username%. Terminal Server will automatically create the username subdirectory and give it appropriate permissions. By default, each user will have full access to his or her own home directory and administrators can copy files into the directory but not read or delete files there.

The Windows and System subdirectories will also be created within the new home directory. Administrators will be given Full Control of these directories.

After you have created the home directory, copy any files in the existing home directory under the user's profile to the new home directory. You can then delete the old home directory.

The preferred way to create home directories is to create a hidden share for every user, like JoeDoe$, and connect the users to it using the NET USE W: /Home command during the logon script or through a persistent connection. You can modify individual application compatibility logon scripts so applications will use the user's home directory to store files and application data.

Using System Policies

A system policy is a set of registry settings that together define the computer resources available to a group of users or an individual. Policies define the various facets of the desktop environment that a system administrator needs to control, such as which applications are available, which applications appear on the user's desktop, which applications and options appear in the Start menu, who can change attributes of their desktops and who cannot, and so forth. Administrators can use policies to manage Terminal Server without increasing SAM size.

For more information on using policies and profiles, see Policies vs Profiles in the Resources section (Included in self-extracting file Tsdeploy.exe as Policies vs Profiles.doc). For help setting up system policies, see Microsoft Knowledge Base Article 168579, How to Set Up Locally-Based System Policies, in the Resources section (Included in self-extracting file Tsdeploy.exe as 168579 - System Policies.doc).

Changing the Logon Process

You can keep the Windows NT logon scripts simple by adding a system variable that can be used to evaluate the presence of Terminal Server. Consider adding a server-based variable called %terminalserver% that allows different actions to execute during the logon script processing. For example, you may choose to omit the execution of the Microsoft® Systems Management Server or anti-virus software if the script determines that it is running on Terminal Server.

Rent-a-Car, Inc., used the following script to prevent Systems Management Server from executing when Terminal Server is used:

REM Logon Script 
Echo Welcome to RACI's Windows NT network 
REM Do not execute SMS if using Terminal Server 
IF %TERMINALSERVER% == NTST GOTO NOSMS 
REM Execute SMS script 
Call SMSLS.BAT 
GOTO END 
:NOSMS 
REM Terminal Server section 
... 
:END 
CLS

Editing User-Specific Information

When users log on to the system, Terminal Server executes a batch file called UsrLogon.cmd in the System32 directory to make any modifications to the end-user environment and ensure that users can run their applications correctly. If Terminal Server modifications are necessary to the user environment, you can make them by editing this file. The registry key that controls when this file is executed is found at HKEY_LOCAL_MACHINE \software \Microsoft \Windows NT\currentversion\winlogon\AppSetup.

Designing for Remote Access

Terminal Server can provide remote users with access to applications that would otherwise be unusable because of poor performance across dial-up connections. (The screen, mouse, and keyboard information sent by Terminal Server typically uses less bandwidth than an application that must be downloaded and then run locally on a remote user's machine.) For reasons mentioned previously concerning using Terminal Server as a domain controller, we do not recommend that Terminal Server itself provide remote access services. Instead, install a dedicated RAS server to provide connectivity to a server running Terminal Server and the rest of the corporate network.

Terminal Server used in conjunction with RAS server

Terminal Server users can also take advantage of Microsoft Point-to-Point Tunneling Protocol (PPTP) to gain access to Terminal Server over the Internet. By using encryption, PPTP provides secure access to a private network for users operating over a public medium. You can find information on the configuration and use of PPTP at https://www.microsoft.com/communications/morepptp.htm.

The following illustration shows a personal computer connecting from a remote location to a corporate network by using PPTP.

Terminal Server and point-to-point tunneling protocol

Terminal Server will also operate through a firewall as long as the firewall can be successfully configured to pass RDP (TCP port 3389). The two traditional categories of firewalls are:

• Packet filtering firewalls can differentiate traffic based on the network address (source or destination) and the session and application-level protocols being used to carry data. For example, the firewall may allow traffic from a certain network address while dropping all other traffic. Or, it may open a certain TCP or User Datagram Protocol (UDP) port (53 for example) to allow DNS zone transfers or queries to complete successfully. Most commercially available routers come with packet filtering capability. RDP uses TCP port 3389.

• Proxy firewalls act as intermediaries between client computers located on a private network and the Internet. All traffic from clients is sent to the proxy that, as its name implies, then acts on behalf of the client on the public Internet. Direct connections between client computers and host residing on the Internet are never established.

Both types of firewalls have advantages and disadvantages. When dealing with a proxy firewall, however, you should verify that the firewall software can act as a proxy for all protocols that you require. When in doubt, contact your firewall vendor.

Security requirements vary considerably from organization to organization. Therefore, a qualified security specialist should review any plans for connecting a private network to a public network to implementation.

Rent-a-Car, Inc., wanted to give outside parties (such as travel agencies) access to Terminal Server over the Internet so they could use the custom Visual Basic application that serves as a front end for RACI's reservations database. RACI created a separate domain, TermServ*, with no trust relationships to any other domains in the RACI corporate network. After opening port 3389 on the exterior router, the deployment team put a server running Terminal Server in the* TermServ domain and created user accounts for the travel agencies that had requested access to the reservations system. The agencies use the Terminal Server client (with encryption enabled) to connect to the reservations server over the Internet and run the Visual Basic application. The TermServ accounts cannot be used anywhere else in the RACI network. In addition, packet-filtering rules on the firewall and on the interior router prevent Terminal Server from gaining access to any resources on the network other than the reservations database.

Terminal Server used with a firewall

External router

Source	Subnet Mask	Destination	Subnet Mask	Protocol	Port
*	*	192.168.1.0	255.255.255.0	TCP	3389
192.168.1.0		*		TCP	3389
*	*	192.168.1.0	255.255.255.0	TCP	80
192.168.1.0	255.255.255.0	*	*	TCP	80

Internal Router

Source	Subnet Mask	Destination	Subnet Mask	Protocol	Port
192.168.1.0	255.255.255.0	192.168.3.0	255.255.255.0	*	*
192.168.3.0	255.255.255.0	192.168.1.0	255.255.255.0	*	*

Planning Infrastructure: Network Considerations

Generally, you should consider the network infrastructure when deploying Terminal Server. This step is especially important when you are replacing legacy systems with Windows-based terminals or personal computers and you must connect these new systems to the network so they can gain access to Terminal Server.

In some organizations, you will need to make very few infrastructure changes when you add Terminal Server. In most cases, however, effective deployment will depend on careful planning in a number of areas related to the infrastructure.

Planning Infrastructure: Wiring

When you add any new systems to the network, be sure to include a physical path to the servers and domains to which they need to gain access. Take particular care to configure routers correctly to establish a network path from the client system to the server.

Place all servers running Terminal Server on a backbone for optimal bandwidth usage. Use the highest bandwidth segment available on your network—do not use a 10-Mbps segment if a 100-Mbps segment is available. 100 base T provides the maximum freedom for future expansion.

Users who gain access to Terminal Server over a dial-up connection must use a modem that connects at 28.8 kbps or faster.

Planning Infrastructure: DNS

You can configure clients to use Domain Name System (DNS) to connect to Terminal Server. Ensure that an address record exists for the servers running Terminal Server in the appropriate zone file.

You can use DNS for load balancing, to distribute work between two or more identical servers. You can accomplish this by using DNS round-robin, in which a single name record resolves to more than one IP address, each with a corresponding cloned server. When a request comes in to the DNS server Services for a computer name, the server assigns it to one of the servers running Terminal Server registered to the name. The next request that comes in will be assigned to the next IP address in sequence. After the last address in the list handles a request, the DNS Service loops back to the beginning and waits for the next request. A client connecting to a server running Terminal Server will spend its entire session on one server; work will not be distributed between other computers.

You should disable session disconnect on servers running Terminal Server that are part of a DNS round-robin setup. Because a client could connect to any of the servers, it might connect to a different server than the one on which a disconnected session was left running.

With DNS round-robin, if one server goes down any requests that the DNS Service assigns to that computer will fail. For example, if you assign four servers to a single name and one server goes down or is taken offline, one-fourth of all requests will fail. The Terminal Server client compensates for this automatically by attempting to connect to the next available server if the first request does not result in a connection. However, these additional requests will delay client startup. If you take a server down for maintenance, always remove that server's IP address from the DNS database to prevent failed requests.

DNS is not dynamic; it does not propagate changes to the database through the network as they are made. When you make changes to the DNS database as described above, you must initiate a zone transfer to propagate the change to other servers on the network. Otherwise, the other nameservers will not receive the changes until the next scheduled update, which may not happen for minutes or even hours.

If the network is not set up for DNS, you can use WINS alone for name resolution, but clients on non–WINS-compatible computers will be able to connect only to the server using IP addresses. In addition, you cannot use WINS for round-robin load balancing, so computers connecting in a non-DNS environment will not be able to take advantage of this method of load balancing.

For additional information on using DNS round-robin for load balancing, see Using DNS to Simulate Load Balancing with Microsoft Windows NT Server 4.0 – Terminal Server Edition in the Resources Included in self-extracting file Tsdeploy.exe as DNS Load Balancing.doc).

Planning Infrastructure: WINS

You can configure Terminal Server so that clients can connect to it using Windows Internet Naming Service (WINS). If you select this method for name resolution, you must register all servers running Terminal Server with the primary and backup WINS servers.

It is possible, though not recommended, to set up a server running Terminal Server as a WINS server. In such a case, make sure the server is registered with itself, with the same address listed for both the primary and secondary servers. See Microsoft Knowledge Base article 150737, Setting Primary and Secondary WINS Server Options, in the Resources Included in self-extracting file Tsdeploy.exe as 150737 - WINS Servers.doc) for more information.

Planning Infrastructure: DHCP

Windows NT Server can use dynamic host configuration protocol (DHCP) to dynamically assign IP addresses to any client that connects to the network and requests one. If you plan to use DHCP, you should also use WINS and Microsoft DNS so clients can easily locate the servers running Terminal Server. An alternative, if you're not using Microsoft DNS, is to add the Terminal Server IP addresses to the DNS host tables. You should always assign static IP addresses to all servers, including the servers running Terminal Server.

Client computers take advantage of DHCP by leasing addresses. When a client comes online and announces itself to DHCP server Service, the server assigns it an IP address for a specific length of time. In most cases, the client stores the lease information locally and retains the address until the end of the lease period if it disconnects and reconnects again at a later time, even if it cannot find DHCP Service on the network upon reconnecting.

Some Windows-based terminals, however, are unable to store lease information locally and rely on DHCP Service to remember their lease assignments. If such a terminal is turned off and restarted, it will request a new IP address from the server. If only a single DHCP Service server is handling requests from this particular scope, it is likely that the same address will be used. If the scope is divided into multiple DHCP Service servers for redundancy, however, a different address may be assigned. This can "use up" a large number of IP addresses because DHCP Service will not reassign them until their lease intervals have expired. If you are deploying Terminal Server into a network with multiple servers running DHCP Service and Windows-based terminal, you should minimize the lease intervals and instruct users not to turn off their terminals.

The lease interval in this case should not be too long. Generally, lease intervals should be less than two weeks, depending on the number of network addresses available to clients.

Planning Infrastructure: Vendor Networking

The Terminal Server client requires TCP/IP to connect to the server, but Terminal Server itself can use IPX to gain access to Novell servers if necessary.

Terminal Server users can be authenticated by and use resources in a NetWare 3.11 or higher environment. Applications running on Terminal Server must be able to operate in a NetWare bindery environment because NDS-specific application programming interfaces (APIs) are not supported. To make IPX connections with other servers, install Windows NT Gateway Services for Novell on Terminal Server. To reduce overhead, disable Distributed COM and NetBIOS advertisement over the IPX protocol stack.

Refer to Microsoft Knowledge Base article 156203, How to Disable Installation of NWLink NetBIOS, in the Resources Included in self-extracting file Tsdeploy.exe as 156203 - NWLink NetBIOS.doc) for information on disabling advertisements.

To remove any Distributed COM advertisements in a Novell NetWare environment, the system administrator must edit the registry to advertise the service through the service advertising protocol. Under the key HKEY_LOCAL_MACHINE \Software \Microsoft \Rpc\ServerProtocols, delete the following values:

NCAN_SPX = RPCLTSCM.DLL

NCADG_IPX = RPCLTSCM.DLL
NCACN_NB_IPX = RPCLTSCM.DLL

If the entire network uses IPX and not TCP/IP, you must either add TCP/IP or install the MetaFrame add-on from Citrix Systems. In that case, end users must use the MetaFrame client software to connect to Terminal Server over IPX.

If Terminal Server must communicate with IBM mainframes or another device that uses systems network architecture (SNA), you should consider using software like Microsoft SNA Server to establish connectivity. With SNA Server, clients can use the routable TCP/IP protocol to communicate with SNA mainframes. Programs that use Advanced Program-to-Program Communications (APPC) to communicate are called transaction programs. Transaction programs use APPC Logical Unit (LU) (LU 6.2) names to gain access to other systems and other transaction programs. These LU names are typically assigned based on the computer name, which prevents them from working correctly in a Terminal Server environment because multiple users use the same computer name. Microsoft SNA Server version 4.0 Service Pack 1 makes special accommodations to facilitate this level of interaction.

Planning Infrastructure: Firewalls

If the organization uses a firewall for security, remember to keep port 3389 open for RDP connections between the client and server. For best results, use a firewall that employs user-based authentication. A firewall that grants access based on IP address will allow through every user of a server running Terminal Server if the IP address of that server has been granted access.

Planning Infrastructure: IP addresses

Terminal Server cannot pass the IP address of individual clients along to an application. Multi-user applications that require each user to have a unique IP address will not work properly because every user will appear to originate from the IP address of the server itself. Certain security applications, such as firewalls, are designed to require unique IP addresses in this way. You may need to alter plans to use Terminal Server to support any such applications.

Planning Security

As with any computing project, planning a Terminal Server deployment requires attention to security issues to ensure the safety of your data.

Although the suggestions in this section will help you plan and implement Terminal Server securely, they are not a substitute for a comprehensive, professional security plan and should not be considered security recommendations.

Planning Security: File System

Because of the multi-user nature of Terminal Server, we strongly recommend that you use Windows NT file system (NTFS) as the only file system on the server, rather than file allocation table (FAT). FAT does not offer any user and directory security, whereas with NTFS you can limit subdirectories to certain users or groups of users. This is vitally important in a multi-user system like Terminal Server. Without the security that NTFS provides, any user will have access to every directory and file on Terminal Server, including important system files and other people's work.

You can increase the security of the logon procedure by disabling the guest account and configuring Terminal Server so the last user's account name does not display in the logon dialog box. See Microsoft Knowledge Base article 114463, Do Not Display Last Logged On User Name, in the Resources Included in self-extracting file Tsdeploy.exe as 114463 - Last User Name.doc) for instructions.

If you want to install Internet Information Services on Terminal Server, you should disable anonymous FTP to prevent unsecured access to the file system.

Part of a good security plan also includes removing services that are not used. Removing the IBM OS/2 and POSIX subsystems will prevent users from executing OS/2 or POSIX applications that circumvent security regulations. The registry key that allows removal of the subsystems is located under HKEY_Local_Machine \System\CurrentControlSet\Control\SessionManager\Subsystems. Remove any text associated with the key value to remove the subsystems.

Planning Security: Recycle Bin

By default, all users have permission to set properties on the Recycle Bin. You can use the Registry Editor, REGEDT32, to change this permission.

Locate and highlight the key called BitBucket under HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Explorer. (If no changes have been made to the Recycle Bin, the BitBucket key will not be present and you must create the key using the Registry Editor or modify a Recycle Bin property and let the system create it automatically.) Click Permissions and change permissions for the group Everyone from Full Access to Read. With this setting, users can see the contents of the Recycle Bin and retrieve items from it but cannot modify its properties.

After making the change, exit from the Registry Editor. Changes will be implemented dynamically.

Planning Security: Communications

Use care in deploying RAS to provide a modem link from Terminal Server to another system. Terminal Server does not limit user access to RAS, so if one user establishes a modem link to the Internet or another system, every user on Terminal Server will have access to the link.

Planning Security: Encryption

You can assign data transfers between the client and server at one of three different levels of encryption.

• With low encryption, traffic from the client to the server is encrypted using the Microsoft-RC4 algorithm (a modified RC4 algorithm with improved performance) and a 40-bit key, whereas traffic from the server to the client is unencrypted. Low encryption protects sensitive data like password entry and application data; the only data sent from the server to the client are screen refreshes, which are difficult to intercept even when unencrypted.

• With medium encryption, traffic in both directions is encrypted using the Microsoft-RC4 algorithm and a 40-bit key.

• With high encryption, traffic in both directions is encrypted using the industry-standard RC4 algorithm and a 128-bit key in the North American version of Terminal Server only. In the export version of Terminal Server, high encryption uses industry-standard RC4 and a 40-bit key.

The encryption level is set server-wide, rather than individually, for each client. For optimal performance, you should use low encryption unless every client connecting to Terminal Server will be running on Pentium or higher microprocessors. On-the-fly decrypting consumes significant CPU overhead on older processors and can lead to unacceptable performance degradation. Additionally, U.S. export regulations prohibit the export of 128-bit encryption outside the United States and Canada. In some cases, Point-to-Point Tunneling Protocol (PPTP) might be a better solution for encrypting traffic between a remote client and a server running Terminal Server because PPTP encryption and decryption consume fewer CPU cycles than the high encryption of Terminal Server.

If you must accommodate older processors or users outside the United States and Canada but still want to provide enhanced encryption to users who can take advantage of it, consider deploying two or more similar servers with different encryption levels. Users with legacy hardware could connect to the server running low encryption, whereas users with Pentiums would connect to a server running medium or high encryption. International users could connect to a server running low or medium encryption regardless of client hardware.

An alternative would be to configure the encryption level on a per-user basis. This approach allows all users to take advantage of the same server, but maintaining the user list requires additional administration. If a user travels outside the United States, for example, the administrator would have to configure the server to communicate with the user's client using low or medium encryption.

Planning Security: System Policies

Terminal Server supports a number of new policies to configure user access. You can use one policy to prevent users from changing the file associations. You can use another policy, available on the Windows NT Server 4.0 Service Pack 4 CD-ROM, to control the size of a user's Windows NT user profile. You can use this policy to prevent users from creating unusually large profiles. You may also want to consider disabling the caching of Windows NT user profiles. You can use other new policies to remove the Windows NT Security, Disconnect, or Log Off commands from the Start menu. The following table lists the new policies available under Terminal Server.

Terminal Server Policies

Description	Policies
Remove the NT Security item from the Start menu	POLICY !!NoNtSecurityMenu VALUENAME "NoNTSecurity" END POLICY
Remove the Disconnect item from the Start menu	POLICY !!NoDisconnectMenu VALUENAME "NoDisconnect" END POLICY
Remove the Log Off item from the Start menu	POLICY !!NoLogoffMenu VALUENAME "NoLogoff" END POLICY
Disable file type associations	POLICY !!NoFileAssociate VALUENAME "NoFileAssociate" END POLICY

You can implement policies on a per-server or per-domain basis. Administrators implementing policies on a per-domain level should install objects to the server, not in user accounts. For more information, refer to Microsoft Knowledge Base article 168579, How to Set Up Locally Based System Policies, in the Resources section (Included in self-extracting file Tsdeploy.exe as 168579 - System Policies.doc).

Organizations in which the same users will use Terminal Server and Windows NT Workstation should use policies with care because the same policy will apply to the users' sessions on Terminal Server and on Windows NT Workstation.

Planning Security: Applications

Administrators can control user access to applications in a number of ways.

Both mandatory profiles and system policies can specify which applications are visible to the user. In addition, system policies can actually prevent users from launching applications through the Windows Explorer shell whereas profiles only hide them. Users can launch hidden applications either by using the Run command or by launching an embedded object unless a policy is in place that prohibits it. User policies are domain-based, so they can affect users' own desktops as well as their Terminal Server sessions.

Take care, therefore, when developing user policies because poorly written policies can prevent users from gaining access to programs on all workstations within a domain, rather than just on Terminal Server. If the administrator implements a policy that is based on a user ID or Windows NT group, whatever is specified in that policy applies to that user or group regardless of what system they use. For example, a policy that prohibits accounting users from running Microsoft Word will affect all accounting users in the domain whether they are using Terminal Server or just their local workstations.

The Application Security option available with Terminal Server allows an administrator to secure a Terminal Server computer so that only specified applications can be launched. Application Security affects all users on a server, so the administrator would need to manually configure the available applications and may need additional servers to support a variety of user needs.

The administrator must also register every application to which users need to gain access. This can be tricky with applications that call other executables because the administrator must determine all of the combinations of executables before the application will run correctly. At a minimum you want to make sure that Explorer.exe and SysTray.exe are registered; otherwise, users will not be able to start the Terminal Server session or view the task bar. You should register other applications to ensure the logon process works correctly including cmd.exe, subst.exe, xcopy.exe, net.exe, regini.exe, and any applications referenced in the application compatibility logon scripts.

The Rent-a-Car, Inc., human resources department manages a benefits tracking system that is used by employees at various locations throughout the company. Because the Windows-based benefits application could be somewhat resource intensive, the HR department wanted to limit access to the system so that the benefits application would be the only application running on the server most of the time. The deployment team installed the application on the HR Terminal Server and used the Application Security Tool to restrict access to other applications on the system. Users without administrative privileges can gain access to the benefits application and nothing else.

Planning Security: Microsoft ActiveX

Because Microsoft® ActiveX controls will execute only if they have been installed in the System32 directory, only the administrator has the ability to install the control for all users. Users have the Creator Owner permission necessary to install controls in the System32 directory, but only the first user of a given control will be able to execute it correctly. If a user visits a Web page with an ActiveX control that another user has already visited, the control will not load unless an administrator reinstalls it on Terminal Server. If the organization's intranet uses ActiveX, therefore, the administrator should inventory all ActiveX content on the site and install the controls to which users will need access. Users who require access to ActiveX controls on external Internet sites should contact the administrator and request that the controls be installed correctly.

Planning Security: Auditing

Administrators can use auditing to keep track of users and files by enabling Auditing in User Manager. For better results, increase the size of the audit log to at least 5 MB and set the system to shut down or to roll over when the log is full.

Use the following table as a guide to change the auditing settings in User Manager.

Sample Audit Policy Window

Feature	Default setting	Recommended setting
Replace Auditing on Subdirectories	Not selected	Not selected
Replace Auditing on Existing Files	Not selected	Not selected
Events to Audit—Read	Not selected	Failure
Events to Audit—Write	Not selected	Failure
Events to Audit—Execute	Not selected	Failure
Events to Audit—Delete	Not selected	Success
Events to Audit—Change	Not selected	Success and Failure
Events to Audit—Take Ownership	Not selected	Success and Failure

See Microsoft Knowledge Base article 149393, CrashOnAuditFail Activates on Shutdown with ProcessTracking, in the Resources section (Included in self-extracting file Tsdeploy.exe as 149393 - Audit Log.doc) for more information.

Planning Security: User Rights

Terminal Server is distributed with a default set of user rights that you can change for extra security.

Another important reason to avoid configuring Terminal Server as a primary or backup domain controller is that any user rights policies you apply to such a server will then apply to all domain controllers in the domain. For example, to use Terminal Server, users must be authorized to log on locally; if the server running Terminal Server is a domain controller, users will be able to log on locally to all domain controllers in the Terminal Server domain.

See the following table for more user rights suggestions.

Sample User Rights Window

Feature	Default setting	Recommended setting
Access to this Computer over the Network	Administrators, Everyone, Power Users.	Replace Everyone with Power Users. This will ensure that only administrators can gain access to resources on a dedicated Terminal Server.
Change System Time	Administrator, Power Users	Remove Power Users.
Debug Programs	Administrators	Remove Administrators; this right is not audited and should not be assigned to any user.
Force Shutdown from a Remote System	Administrators, Power Users	Remove Power Users.
Log on Locally	Administrators, Backup Operators, Guests, Power Users, Users	Remove Guests. Replace Everyone with Domain Users.
Shut Down the System	Administrators, Backup Operators, Power Users, Users	Remove Power Users. Users should not have the ability to shut down a file server.

For an example of a configured system, see Sample Security Configuration in the Resources section (Included in self-extracting file Tsdeploy.exe as Sample Security Configuration.doc).

Planning Security: Auto Logon Procedures

Depending on how people will be using Terminal Server, you may need to grant them access to the file system. Users who only need access to a single application, like a database front end, can be put directly into the application at startup.

You can also use the Connection Configuration Utility to configure the server to allow users to connect without entering a username and password. Generally, you should plan to use this connection method only when users will be logged directly into a line-of-business application, especially when the application itself requires a password for access. Use this feature with care because it means that anyone with a Terminal Server client can log on to the server.

You can implement auto logon policies server-wide or on a per-user basis. Use Client Connection Manager to implement policies for users and Connection Configuration Manager for the server itself. A server-wide auto logon policy is appropriate when a server is dedicated to a particular task-based application. If a server will host more than one application, you should assign auto logon privileges by user.

Rent-a-Car, Inc., plans to deploy Windows-based terminals at the reservations center running 3270 emulators to connect to the reservations mainframe while the center transitions to a Windows-based database system. RACI often hires temporary employees for its Macon reservations center during heavy vacation periods like Memorial Day, Thanksgiving, and Christmas. To decrease maintenance and training costs, the IS department plans to configure the reservations servers running Terminal Server to automatically connect all clients without requiring a username and password. As a client connects, Terminal Server automatically launches the 3270 application and connects to the reservations mainframe, which requires password access. This way, a user has to enter a username and password only once.

Planning Security: GINA

You can modify the Graphical Identification and Authentication (GINA) DLL, which is part of the Windows NT logon subsystem, to provide support for smart card systems, retinal scan systems, or other authentication mechanism in place of the standard Windows NT username/password authentication routine.

We recommend that you not modify GINA under Terminal Server. You must make GINA modifications using the standard Windows NT SDK, which does not support certain Terminal Server features such as session reconnection and Windows-based Terminal Server client credential passthrough. A modified GINA could therefore not support these features.

Planning Security: Passwords

Good passwords play a key role in securing a computing environment. By implementing a policy to require strong passwords, you can make it more difficult for would-be intruders to foil your security precautions.

For more information about implementing strong passwords, see Microsoft Knowledge Base article 161990, Implement Strong Passwords, in the Resources section (Included in self-extracting file Tsdeploy.exe as 161990 - Strong Passwords.doc).

Planning Server Deployment

Administering Terminal Server can be made much easier if the server computers used are purchased from the same vendor and configured similarly or identically. If you are deploying Terminal Server to serve different needs or activity levels, consider dividing the servers into groups based upon function and making the servers in each group as similar as possible.

If the organization uses equipment standards, try to adhere to the standards when planning new hardware acquisitions. Even if the existing standards don't address the server-caliber computers necessary for an effective deployment of Terminal Server, you might be able to scale up from the standard to keep hardware and software administration and maintenance as simple as possible.

Consult the information systems department within the organization when planning any new acquisitions. Items to consider include storage, memory, swap and dump files, CPUs, fault tolerance, network adapters, backup, registry, and ICA connections.

Storage

Small computer standard interface **(**SCSI) hard disk drives provide faster throughput and better performance than integrated device electronics (IDE) drives. You should duplex or array drives in a hardware RAID 5 for increased reliability; see below for more information on fault tolerance.

Memory

A good principle is to install 32 MB on every server plus at least 4 to 8 MB per simultaneous user expected. For example, a server intended to support 15 simultaneous users would require a minimum 152 MB of physical RAM (152MB= 32MB+8MB*15 users). If users will be running memory-intensive applications, such as a client/server application with a large memory footprint, you should increase the amount of RAM allocated for each user. Each server should have enough physical memory to ensure that the swap file is almost never used. Terminal Server uses round-robin thread scheduling, so when one user hits the swap file, performance decreases for all users.

Swap and Dump Files

The amount of disk space devoted to each server's swap file should be at least 1.5 times the total amount of physical RAM.

It's a good idea to put the Terminal Server operating system on one physical drive and assign the swap file to another. If the server will have a large amount of physical memory, you should consider whether the hard disk drive space is sufficient to record the dump file on the system partition. Consider such factors as total memory, swap file size, installed applications, and the total size of the hard disk drive. For better performance, the swap file should be on a separate physical disk. Consider disabling the dump file on systems with large amounts of RAM (typically 128 MB or more), unless drive C is large enough to hold the dump file. Consider installing another Windows NT–based system connected through serial interface to Terminal Server for debugging purposes so Microsoft Technical Support can debug the servers over the phone if necessary.

The maximum number of page table entries (PTEs) that can be created is 50,000. The system will subtract from this value if it must initialize a large non-paged pool. The system will typically allocate PTEs based on an estimate of the memory size of the computer, with about 7 KB being the base for small memory, 11 KB for less than 19 MB, and 22 KB for greater than 19 MB. On Terminal Server, maximize this value to 50 KB if more than 64 MB of memory is available. This will require 28 pages of additional memory over Windows NT Server 4.0, or 115 KB.

The default for PTEs in the registry should be 0. The operating system changes the amount allocated as described above based on system memory size. A fixed size of 10 KB in the registry would not address the machine's size. The rationale is that larger machines are capable of supporting more users, processes, and threads. All of these structures take PTEs for non-paged pool growth, thread kernel stacks, input/output (I/O) mapping buffers, and so forth.

Empirical tests suggest that an "average" session consumes 23 to 25 threads. Of these, 75 percent were graphical user interface (GUI) or large kernel stack threads. This is about 328 PTEs per session for kernel stacks alone. Some PTEs are consumed for additional non-paged pool allocations such as open files, but this impact is smaller than the kernel stack load. Some transient PTEs are also used in the operation of I/O and certain system calls. This transient load is shared above all sessions, but a baseline must be available to prevent the system from running out. Transient load is specific to the work load.

Terminal Server uses PTEs to map the location of physical memory pages. Each user who logs on to Terminal Server requires a minimum of 200 PTEs. If the PTE pool is exhausted, additional users will be unable to log on. For large servers, you should set the number of PTEs to the maximum limit of 50,000.

To set the page table entries to the maximum limit:

1. Start Registry Editor, REGEDT32.EXE.

2. Open the key HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control\SessionManager\MemoryManagement.

3. Double-click the SystemPages value. The DWORD Editor dialog box will appear.

4. Select Decimal in the Radix box.

5. Enter 50000 in the Data text box.

6. Click OK to save the changes and exit the Registry Editor.

CPUs

Terminal Server should run on a 200-MHz Pentium Pro at a minimum. You can expect to support between 15 and 25 simultaneous users per processor. Consider buying servers that can support more than two processors for scalability purposes. Terminal Server as shipped will support up to 4 processors; OEM versions may support up to 32 processors.

Some multiprocessor architectures and hardware abstraction layers (HALs) do not support dynamic interrupt distribution. In these cases, a network adapter is typically bound to a single processor. A single process would therefore handle all interrupts from a given network adapter, and the bulk of the processing would occur on a single CPU. We recommend that you either consider systems that support dynamic interrupt distribution, install multiple network adapters to distribute the load, or disable processing affinity by using the Registry Editor to set the key HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NDIS\Parameters\ProcessorAffinityMask to 0.

For more information, see DPCs and Dynamic Interrupts in the Resources section (Included in self-extracting file Tsdeploy.exe as DPCs and Dynamic Interrupts.doc).

Fault Tolerance

Consider using a hardware RAID 5 to protect data and help ensure speedy recovery from disk failure. Software RAID 5s require additional processing overhead and could degrade performance. ECC error correcting memory can help increase reliability. Follow the same hardware and data safety procedures you would use for any other server, such as putting all servers running Terminal Server on an uninterruptible power system (UPS) and locating them in an environmentally controlled room.

Network Adapters

Use a high-speed network adapter with each server. Consider separating network access so that users connect to the server through one adapter and the server connects to other servers on the network through another.

Backup

Use a backup tool that is capable of backing up the Windows NT registry, and use a tape drive that is large enough to back up all data on the system. Consider using the Rdisk utility of Terminal Server to back up the registry to a safe, redundant location. If you are locating a server in an area where maintenance technicians will not have easy access to it, consider using backup software that can communicate and issue alerts remotely.

Registry

The default Windows NT registry size is 12 MB. This may not be sufficient to support the larger user profiles that Terminal Server creates. The baseline registry consumed is the size of the System, Software, and local SAM hives in %SystemDir%\config. This is about 6.5 MB on a typical Terminal Server machine. The per-session additional registry quota is a function of the size of the user's profile that is loaded under HKEY_CURRENT_USER. Typical Windows NT profiles are about 400 to 600 KB, but some can be as large as 1.2 MB per user if per-user class associations is enabled, so plan to increase the default registry size. The system maximum is 204 MB.

If you will be adding attributes specific to Terminal Server to user accounts, consider increasing the registry size on the domain controllers to accommodate the larger SAM.

ICA Connections

If you want to make connection available to clients using the ICA protocol, you must install the MetaFrame software from Citrix Systems on Terminal Server.

Planning Client Deployment

Personal computers or terminals connect to Terminal Server using a small client program installed on disk or in firmware. The choice of client platform to use will depend on the current installed base and individual user need. At a minimum, ensure that every client computer or terminal that you expect to connect to Terminal Server is physically capable of hosting the client software and connecting over the network. Possible Terminal Server client devices are summarized in the next three sections.

For help in deciding the most appropriate client device for a given user, see Choosing the Best Windows Platform from a Business Perspective in the Resources section (Included in self-extracting file Tsdeploy.exe as Choosing the Best Windows Platform.doc).

Deploying to Windows-based Terminals

The term "Windows-based terminal" broadly describes a class of thin client terminal devices that can be used to gain access to servers running a multi-user Windows operating system such as Terminal Server. Windows-based terminals can be divided into two categories. One category of terminals (referred to hereafter as "Windows CE–based terminals") is based on a version of the Microsoft Windows CE operating system and connects to servers using RDP. Some manufacturers of Windows CE–based terminals may also include support for the ICA protocol. The other category consists of terminals that use proprietary operating systems and connect to servers using the ICA protocol only.

Windows CE–based terminals are generally the most "Windows-like" terminals that can be used to gain access to Terminal Server. These terminals are set up and configured using wizards running the familiar Microsoft® Win32® user interface found in Windows 95 and later Windows-based operating systems. Windows CE–based terminals may also include emulators for other terminal types as part of the firmware. Users of such terminals may establish simultaneous connections to different types of servers and hotkey between the different emulators on the terminal device.

ICA-only terminals can connect to Terminal Server if Citrix Systems MetaFrame is used to add ICA protocol support to Terminal Server. Some ICA terminals can be flash upgraded to support RDP as well. Consult the terminal vendor for more information.

Consider purchasing terminals from vendors that can provide a tool that will enable administrators to perform batch upgrades to flash ROM and asset management from a remote location.

Windows-based terminals can typically be configured locally for a number of parameters, including:

• Whether to use DHCP.

• Whether to connect using 10 base T, Point-to-Point Protocol (PPP), or a serial port.

• IP address, subnet mask, and gateway.

• Whether to enable DNS to look up the Terminal Server name when establishing a connection.

• Whether to use a local host file.

You can use some Windows-based terminals to gain access to Terminal Server over a dial-up connection using PPP. Note that, because many Windows-based terminals do not support encryption during the logon process, you must configure the device used to provide connectivity to the Terminal Server network for plain-text passwords or a connection will not be established.

Refer to https://www.microsoft.com/ntserver/ for a list of several leading vendors offering Windows-based terminals.

Deploying to Personal Computers

Windows-based personal computers connecting to Terminal Server should have at least an 80386 microprocessor running at 33 MHz, a 16-bit VGA video card, and the Microsoft TCP/IP stack. The Terminal Server client will run on Windows NT or Windows for Workgroups 3.11 or above. Computers running Windows 3.1 must be upgraded or use a vendor ICA-based client.

The Terminal Server client takes up only about 500 KB of disk space and typically uses approximately 4 MB of RAM when running. For best performance, a computer running the Terminal Server client should have a total of 8 MB of physical RAM or more under Windows for Workgroups 3.11 and Windows 95 or 98 and 12 MB or more under Windows NT.

Deploying to Non-Windows Computers

Microsoft Terminal Server client is available only to personal computers running Windows for Workgroups 3.11, Windows NT, or Windows 95 or 98, or to Windows-based terminals. Other computers, such as Macintoshes or UNIX workstations, can connect to Terminal Server using ICA-based client software only by using software such as Citrix MetaFrame to make an ICA connection to the server. See the Citrix Web site at https://www.citrix.com for information on minimum hardware requirements.

Following Best Practices

Several tips can help you maximize users' experience with Terminal Server, including minimizing graphics use, mapping local drives and resources, using disconnect sessions, modifying blinking cursors, limiting screen savers, using COM, limiting MS-DOS applications, configuring for applications using NetBIOS, and learning system key sequences..

Minimizing Graphics Use

Animated graphics can slow down the screen refresh rate on the client, creating an impression of diminished performance. Minimize the use of animated graphics within applications and the operating system wherever possible. Disable the system screen saver and either remove the Microsoft Office Assistant or require users to use one of the non-animated assistants.

You can improve the performance of Microsoft Internet Explorer by disabling smooth scrolling. Use the Internet Explorer Administration Kit (IEAK) or set the HKEY_CURRENT_USER \software \microsoft \internetexplorer \main\smoothscroll key to REG_DWORD=0. If this key does not exist, you must create it.

Minimize the use of cascading menus, especially the Start menu. Put shortcuts to commonly used applications on the desktop and keep the Programs submenu as flat as possible by avoiding multiple submenus. Also, use a single-color wallpaper to reduce the number of graphical images that must be transferred over the network.

Administrators can use registry keys to control users' desktops to minimize graphics use. You can use the following registry key to eliminate the animation effects used by the Windows NT 4.0 shell:

HKCU\ControlPanel\Desktop\WindowMetrics\MinAnimate REG_SZ "0"

In addition, you can use a registry hive of Terminal Server to override user setting such as wallpaper, animation effects, and screen savers. Create a key called UserOverride under:

HKLM\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-tcp

Then re-create the user keys and values that you want to override as they appear on the HKCU\Control Panel\Desktop\ key. For example, to override the Windows animation effects for all users, set this key:

HKLM\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-tcp\UserOverride\ControlPanel\Desktop\WindowMetrics\MinAnimate REG_SZ "0"

Mapping Local Drives and Resources

Users who want to access data on local drives from within Terminal Server client can do so by sharing the drives or folders and gaining access to them as remote shares from the server. You can share a floppy disk drive using this method, but Windows requires a disk to be in the shared drive at startup.

You can take a few steps to simplify the remapping of client drives or of local printers. First, enable file sharing on client computers, sharing drives with easily identifiable names like "drivec." Then use the Terminal Server logon script to remap a drive letter to the Terminal Sever. Terminal Server uses a command variable called clientname to provide the NetBIOS name of the system from which the user is gaining access to the server. To map the local boot drive to the letter P on Terminal Server, therefore, you would insert the line

NET USE P: \\%clientname%\drivec

into the script. A similar technique may be employed to support "local" printing.

Users who share local drives across the network should be aware of the security implications. If the user does not control access to local shares, every user on the network will be able to read and copy any file on the shares. Windows NT 3.51 and later allows the user to regulate access to local shares by allowing or excluding specific users. With Windows for Workgroups 3.11, Windows 95, and Windows 98, users can regulate access only with passwords.

ICA-based clients use local drives and resources natively by mapping them to drive letters for the duration of the user's session on Terminal Server. The local drives will not be available for use by other users.

Using Disconnect Sessions

You may want to consider disconnecting the users from their Terminal Server sessions after a period of inactivity to keep server resources easily available to other users. This is especially important in an environment that uses DNS round-robin for load balancing because users could be redirected from one server to another every time they connect.

Modifying Blinking Cursors

A blinking cursor on the remote client session will cause continuous traffic because a small amount of screen refresh data must be sent to the client every time the cursor blinks. This may be a problem in environments that depend in part on slow links such as dial-up connections in which a rapidly blinking cursor could result in performance degradation. If this is a concern, you can modify the cursor blink rate by clicking the Keyboard icon in Control Panel. Setting the blink rate to its lowest setting disables cursor blinking.

Limiting Screen Savers

Prohibit access to some of the more sophisticated screen savers such as 3D Pipes or other OpenGL screen savers. These screen savers are fairly CPU-intensive and severely impact the performance of Terminal Server for other users.

One way to force users to use simple screen savers is to delete all files of type .scr from the root directory except black16.scr, which simply blanks the screen. Another way is to configure the system so that the screen saver is the same for all users. You can do this by instituting a policy or by setting the following registry keys:

HKLM\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-tcp\UserOverride\ControlPanel\Desktop\ScnrSave.EXE
REG_SZ "c:\wtsrv\black16.scr"

HKLM\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-tcp\UserOverride\ControlPanel\Desktop\ScreenSaveActive
REG_SZ "1"

Using Distributed COM

Distributed component object model (Distributed COM) is a mechanism that enables you to run distributed applications across multiple computers in a network. A distributed application consists of multiple processes that cooperate to accomplish a task. These processes may run on one or more computers.

Distributed COM has four activation models: anonymous, in which the server performs processing tasks for the client without knowing the identity of the client application; identity, in which the server application can verify the identity of the client application; impersonate, in which the server application can impersonate the client application only by running tasks as the client application; and delegate, in which the server application can perform processing tasks on another computer as the client application. Terminal Server only supports anonymous connections for Distributed COM applications that Terminal Server itself hosts. Microsoft Transaction Server runs under the fourth activation method and therefore will not run under Terminal Server. Consider installing the server component of MTS on a separate Windows NT system and the client component on Terminal Server.

Limiting MS - DOS Applications

Take care when deploying applications written for MS-DOS. Standard MS-DOS applications will require more memory because each application will spawn its own 16-bit Windows on Windows (WOW) subsystem. The applications could also use nearly 100 percent of the system CPU because they constantly check for keyboard input whether the application is active or idle. Also note that Terminal Server does not support full-screen mode for MS-DOS applications.

See Modifying DOS Application Keyboard Polling Detection in the Resources section (Included in self-extracting file Tsdeploy.exe as DOS Keyboard Polling.doc) for information on configuring MS-DOS applications for use with Terminal Server. For information on configuring Windows 16-bit or 32-bit applications that monopolize the CPU, see Performance Tuning CPU Usage for 16-bit and 32-bit Windows Applications in the Resources section (Included in self-extracting file Tsdeploy.exe as Performance Tuning CPU Usage.doc).

Configuring for Applications that Use NetBIOS

Some applications make use of a NetBIOS function to discover the name of the computer upon which the application is running. These applications may return an error such as "Duplicate NetBIOS Name In Use" when two or more users run the application simultaneously under Terminal Server.

To configure Terminal Server to return the user's logon name rather than the computer name to applications making this NetBIOS call, see Duplicate NetBIOS Name in the Resources section (Included in self-extracting file Tsdeploy.exe as Duplicate NetBIOS Name.doc).

Learning System Key Sequences

Generally, Terminal Server client sessions function similarly to Microsoft Windows NT Workstation 4.0 on the end-user level. However, users should be aware of a few important differences.

Windows users will be familiar with key sequences, such as ctrl+alt+del, that shut down the computer and perform various administrative tasks. However, when a user executes one of these key sequences when running Terminal Server Client on a personal computer, the sequences will affect the operation of the computer itself and not the Terminal Server Client session. Terminal Server provides an alternate set of key sequences to use with the client session.

Terminal Server System Key Sequences

Task	Typical key sequence	Terminal Server key sequence
Open application selector and move selection to the right	alt+tab	alt+pgup
Open application selector and move selection to the left	alt+shift+tab	alt+pgdn
Switch between running applications	alt+esc	alt+ins
Open Start menu	ctrl+esc	alt+home
Right-click running application's Task Bar button	alt+spacebar	alt+del
Open Windows NT Security window	ctrl+alt+del	ctrl+alt+end
Toggle the client screen between full-screen mode and windowed mode	ctrl+alt+break

Printing from Terminal Server

Printing from Terminal Server is similar to printing from other versions of Windows NT 4.0, but users and administrators must take notice of certain important differences.

There are a number of ways to manage networking printing in a Terminal Server environment. Within a small environment, the administrator may want to configure printers locally on the server running Terminal Server. The printers may be locally attached through the parallel port or a network interface. These printers will automatically be available to other users on the system.

In a mixed environment with Novell file and print servers, you may need to establish the print queues on the server running Terminal Server so users can print to the printers available on the Novell network. In this scenario, the administrator must configure the printer drivers on the servers running Terminal Server because users might not have access to them and will not have permissions to install additional printer drivers.

In a Windows NT file and print scenario, managing printers within Terminal Server itself is greatly simplified because the printer drivers need not reside on the server itself. However, the administrator must still manage which users have access to which print queues.

There are a number of ways to deal with this. For some organizations or applications, printing will not be an issue and can be ignored. For others, the situation is not as simple. Some will use a mandatory profile that has the available printers already defined. In this case you may want to define a mandatory profile by facility or floor location because some printers may not be as close to some users as others.

Other situations will require user profiles, but the users will not know how to connect to a printer. One way to facilitate the administrative responsibilities for managing print queues in a Terminal Server environment is to use a tool like Con2prt.exe (included in the Windows NT Zero Administration Kit) as part of the logon script processing. This tool allows the administrator to define or delete which printers are available to any user who logs on to a Windows NT Server domain.

Other considerations when planning printer configuration include:

• If printers are configured to print a banner page for each print job, ensure that the banner page identifies jobs by user name, rather than by computer name.

• If the system administrator restricts user access to Control Panel, users will not be able to add and configure printers for themselves, so the administrator will have to give users access to printers manually. Administrators must therefore keep the consequences of their actions in mind—restricting user access to resources makes those resources the administrator's responsibility.

• A user who wants to print "locally," to a printer connected to the user's own computer, can do so under peer-to-peer networking using the net share command. As with local disk drives, this enables users to gain access to the printer remotely from the server. If the user installs a network card in the local printer, it becomes a network printer and file sharing does not have to be enabled on the user's computer.

  The net share method is designed to work on printers connected locally to personal computers running Windows for Workgroups 3.11 or later. Users of Windows-based terminals running RDP currently cannot print to local printers.

• If users will be gaining access to Terminal Server across a WAN, take care to accurately assess the bandwidth requirements of any print jobs that will be spooled across the WAN. If a user prints to a "local" printer that resides on the user's LAN but across the WAN from the server running Terminal Server itself, the print job will be spooled across the WAN to the printer. This will add to the bandwidth requirements for Terminal Server because the network will be required to handle print traffic as well as keystrokes, mouse events, and screen updates.

Preparing to Install Applications

The procedure for installing applications on a server running Terminal Server is slightly different from that used with other versions of Windows NT Server. Always install applications that will be used by all users from the administrator account using the Add/Remove Programs dialog, not by simply launching the Setup.exe file from Windows Explorer.

Always disconnect all users from Terminal Server and prevent inbound connections from being established before installing any new software intended for multiple users. If the application being installed updates files that are in use, such as DLLs or files from a previous version of the application, system crashes can occur.

As of this guide's publication, the following applications have been tested and will run under Terminal Server with minor or no modifications:

Applications Tested with Terminal Server

Vendor	Applications
Microsoft Corp.	Microsoft Office 95 and 97 Microsoft Office version 4.3 Microsoft Project 95 and 98 Microsoft Internet Explorer versions 3.02 and 4.0 Microsoft® Visual Test Microsoft SNA Server versions 3.0 and 4.0 Microsoft SQL Server version 6.5 Microsoft Access for Windows version 2.0 Microsoft Access version 7.0 Microsoft® Exchange Server version 5.5 Microsoft® FrontPage® 98 Microsoft® Outlook™ 98 Microsoft Internet Information Services versions 2.0, 3.0, and 4.0
Lotus Development Corp.	32-bit Lotus SmartSuite 97
Corel Corp.	Corel Perfect Office version 7.0 Corel WordPerfect Suite version 8.0
Netscape Communications Corp.	Netscape Navigator version 3.0 Netscape Communicator version 4.0

Check with individual application vendors for more information about application compatibility.

The Zero Administration Kit for Terminal Server in the Resources section (Included in self-extracting file Tsdeploy.exe as zak4wts2.exe) facilitates the automated installation and configuration of locked-down Terminal Server sessions. These locked-down sessions provide users with access to one or more specific line of business applications while limiting their access to other applications and parts of the operating system. See ZAK for Terminal Server in the Resources Included in self-extracting file Tsdeploy.exe as ZAKforTS v2.1.doc) for more information.

Installing Applications

Applications need only be installed once on Terminal Server for multiple users to have access to them, but it's important to consider the licensing agreements for all applications installed on Terminal Server. Microsoft Software License Terms require one license per session (including the console) or Windows NT Server CAL used; multiple users require multiple software licenses. Microsoft currently will not support any application that uses a hardware security key on Terminal Server because these devices are designed to limit the use of the software to one system only.

Prior to installing an application and running the compatibility scripts, the administrator must prepare the system for application installation by running Add/Remove Programs on Control Panel or running change user /install and change user /execute from the command prompt. Both of these procedures place Terminal Server in a special mode that captures the installation process of an application so it can be applied to all users using Terminal Server. Add/Remove Programs on Control Panel turns the capture mode on and off automatically, whereas change user /install turns the capture mode on manually. After completing the installation process, the administrator should run change user /execute to turn the capture mode off.

Running change user /install places Terminal Server in install mode. This mode captures all registry and .ini file writes during application installation and redirects them to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TerminalServer\Install, a caching area, for the current session only. Keys added to HKCU are copied under the Software key, whereas keys added to HKLM are added to the machine key.

Avoid running applications while in install mode or installing applications while other users are connected to a server running Terminal Server. Running an application in this mode will also capture registry and .ini file writes, which could affect other users' personal settings for the application. Administrators should also be aware that running or installing an application in install mode while other users are using Terminal Server could damage or reconfigure other applications or otherwise negatively affect the users.

Occasionally, applications require you to reboot the system before you can complete installation. Install mode will capture all registry and .ini writes prior to the reboot. However, Terminal Server always starts in execute mode, in which writes are not captured. If the application installer performs additional writes after reboot, users may not be able to run the application correctly. Always test applications with various user accounts after installation to ensure that they run properly before putting them to work in a production environment. If the application fails under some accounts or if you have prior knowledge that the installer performs additional registry and .ini writes after reboot, consider creating a logon script that places the system back in install mode upon a system reboot.

Install mode is not persistent across logon actions, so when the administrator logs on to the system again, the session will start in execute mode. An exception is for applications, such as Internet Explorer 4.0, that use the runonce key in the registry to continue installation. Applications that are added under the runonce key will be executed in install mode.

The Add/Remove Programs dialog box will revert the system to execute mode automatically or you can issue the change user /execute command to enter execute mode manually. If you leave the system in install mode, users will inherit any changes the administrator makes to the default configuration of the application.

When a user launches an application in executable mode, the system will check for the proper registry entries in HKEY_LOCAL_MACHINE (HKLM) and HKEY_CURRENT_USER (HKCU) and compare them to the entries the system has recorded from the installation. If these entries do not exist, Terminal Server will copy them to the proper locations in HKLM and HKCU.

Applications that use .ini files are treated in a similar manner. When a call is made to an .ini file, the system compares or creates the user's .ini file to the file created during installation.

Generally, when an administrator runs an application in execute mode, any changes he or she makes should affect only the administrator's own account and session. See Running Applications in this section for exceptions to this rule.

Configuring Applications

The Terminal Server distribution includes application compatibility scripts for popular applications such as Microsoft Office, Lotus SmartSuite, Netscape Navigator, and others. These scripts modify applications to function well in a multi-user environment. If the application you are planning to install has a corresponding compatibility script, you should run the script immediately after application installation and before starting the applications for the first time.

An application compatibility script consists of two different components, an installation script and a logon script. The application compatibility installation script typically contains a batch file and a registry file. The batch file creates system directories, modifies file system permissions, executes the application-specific registry file, and configures UsrLogn2.cmd, a file that runs every time a user logs on to Terminal Server and launches the appropriate application compatibility logon scripts. The registry file modifies the registry to either improve the application performance or to modify user configuration settings to accommodate a multi-user environment. The system modifies the UsrLogn2.cmd file simply by appending the appropriate application logon script batch file so that it is executed every time a user logs on.

After an application is installed, the administrator must run the application-compatibility installation script that modifies the application to work in a multi-user environment. The installation script modifies the application's global registry settings and disables functions that could impact the system performance. For example, the Microsoft Office 97 installation script disables the Findfast utility. In addition, the script sets a number of file attributes to read-only to ensure that multiple people can open the files simultaneously.

If an application does not come with compatibility scripts and appropriate scripts are not supplied with the Terminal Server distribution, the deployment team might have to modify the application itself or create compatibility scripts for it. Modifications can include:

• Adding Start menu icons to the All Users group

• Changing file locations to a user's home directory for storing personal user settings

• Registering application DLLs as system global for access by all sessions

• Changing permissions on NTFS directories

• Adding entries to the default user profile

• Modifying other registry or .ini files

It is always a good idea to install applications on a test server first to identify all modifications needed before implementing these changes in a production environment.

Running Applications

The application compatibility logon script is called by UserLogn2.cmd every time a user logs on to Terminal Server and configures the application to use the user's home directory as the working disk area. Logon scripts usually check the user's home directory for user customization files and copy them from the designated directory to the user's home directory if they are not found. These scripts can also add items to the user's Start menu and make changes to the user's HKCU entries in the registry.

As with application compatibility installation scripts, an administrator could be required to create an appropriate logon script if one does not exist for a particular application. Once again, it's best to make these changes on a test server to identify and resolve any issues before putting an application into a production environment.

Some applications fail to work properly even after being modified with application compatibility and logon scripts. When most applications check the registry hive for configuration information, they check HKCU first and HKLM second. If the application finds an entry in HKLM and not in HKCU, it will typically copy the entry to the HKCU. However, some applications check only HKLM for configuration information; this can create an issue in a multi-user environment because one user's changes to the application settings can affect all application users. An administrator can change the permissions on these registry keys to prevent users from modifying their values, but some applications will not operate properly if users cannot change the settings. As always, the deployment team should install applications on a test server to identify any applications that perform this way.

Most applications on the market today store data and configuration files on a dedicated drive. This can cause complications in a Terminal Server environment because all users typically share the same hard disk drive. You must therefore configure the application to write to a unique location for each user.

The application compatibility scripts that ship with Terminal Server assume that all users can store this information as part of their Windows NT profiles. This can cause the size of the profiles to increase, resulting in increased logon/logoff times, increased disk space requirements, and longer backup times. Use the RootDrv.cmd file to choose a different drive to which the application will write configuration and date files. Consider using the user's home directory instead.

Supporting Multilingual and International Users

A single server running Terminal Server cannot simultaneously host multiple system languages. Users will be able to read and create documents using non-Western character sets if the required font files are installed, but Terminal Server will use a single language for menus, dialog boxes, and other system functions.

One way to support users around the world would be to host all users on the international version of Terminal Server. This would ensure that the organization is not in violation of U.S. export laws regulating strong encryption, but might be inadequate if the organization must provide support for different languages.

Another approach would be to have farms of servers with localized versions of Terminal Server and applications dedicated to the different languages that users speak. This way, users could connect to a server that would let them work in their native language.

If the Terminal Server computers will be serving users around the world but all the international users understand English, consider deploying the International English version of Terminal Server. By default, Terminal Server will install all of the available keyboard layouts, including support for Asian non-IME (Input Method Editor) keyboards.

On personal computers running Terminal Server Client, the Client Connection Manager software uses the client computer's settings (typically configured in Regional Settings in Control Panel) to configure the user's Terminal Server session to use the preferred keyboard layout. Regional Settings include such settings as date and currency formatting and are stored in the user's profile, so individual users can adjust the settings to match their locality. A Windows CE–based terminal can only support one keyboard layout at a time, which is loaded into firmware before shipping. Consult the terminal vendor for more information.

Terminal Server keeps track of time according to the time zone in which it has been configured, rather than on a per-user basis. Users located in a different time zone than the server must make allowances for the time difference.

The Rent-a-Car, Inc., Latin America rental locations have until now been required to use RACI's English language reservations database, which has made hiring and training reservations coordinators difficult. During the migration to Terminal Server, the deployment team configured several servers to run the Spanish language version of Terminal Server and used Visual Basic to write a Spanish front end to the reservations database. Now, reservations coordinators in Latin America connect to the server running Spanish language Terminal Server and access the database using the Visual Basic front end, while users in North America and English-speaking Europe connect to the server running English language Terminal Server and use 3270 emulators to access the database as they have always done.

English and Spanish servers running Terminal Server and accessing common data

Upgrading from Windows NT

Microsoft does not recommend upgrading directly from Windows NT to Terminal Server because of changes in the registry and application behavior in a multi-user environment. To upgrade a server running a previous version of Windows NT to Terminal Server, back up all critical user data, then erase the boot disk, install Terminal Server, and restore the data.

There are two ways to optimize performance after completing an upgrade from a previous version of Windows NT:

• Under Optimization in the Server service, select the Minimize Memory Use option.

• In the Windows registry, set HKEY_LOCAL_MACHINE \System

  \CurrentControlSet\Control\SessionManager\MemoryManagement
  \LargeSystemCache to 0.

For more details, see Microsoft Knowledge Base articles 110255, Performance Drops During Large File Copy (Included in self-extracting file Tsdeploy.exe as 110255 - Performance Drops.doc), and 101041, Excessive and Unnecessary Paging File Activity (Included in self-extracting file Tsdeploy.exe as 101041 - Paging File Activity.doc), both in the Resources section.

Upgrading from Citrix WinFrame

You can upgrade Citrix WinFrame 1.6 and 1.7 to Terminal Server without re-installing applications and users. You must install the Microsoft TCP/IP stack on the computer if it has not already been installed.

In WinFrame 1.6, some WinFrame-specific user information is stored in the registry rather than in the OEM fields of the SAM, which is where the extra information is stored in WinFrame 1.7 and Terminal Server. If you plan to upgrade servers running WinFrame 1.6 to Terminal Server, you must first run the CNVRTUC utility from Citrix to transfer the extra information to the SAM.

OEM versions of WinFrame, such as NTRIGUE, WinCenter, and WinDD, might not upgrade to Terminal Server correctly, and Microsoft will not support such upgrades.

Some differences in product features exist between the ICA display protocol used by Citrix WinFrame and RDP supported natively in Terminal Server. It is therefore necessary to install Citrix MetaFrame add-on software on Terminal Server to preserve certain ICA client features. Consider which of these protocol features you will need to make a smooth transition from WinFrame to Terminal Server when deciding whether to deploy the MetaFrame add-on for Terminal Server. To find out more information about WinFrame and MetaFrame, visit the Citrix Web site at https://www.citrix.com or contact your Citrix reseller for more information.

The following steps are required to properly migrate a WinFrame 1.6 or 1.7 server to Windows NT Server 4.0, Terminal Server Edition:

1. Install Terminal Server. Terminal Server installation is almost identical to Windows NT Server installation. For complete step-by-step instructions for installing Terminal Server, please refer to the Start Here document that comes with the program. You can find an electronic copy of this document on your Terminal Server installation CD-ROM at \support\books. Memory configuration requirements, networking protocols, upgrade limitations, server installation, and file partition conversion all have specific roles and requirements in the Terminal Server environment. Be sure to complete the following steps.

2. Back up your WinFrame system completely. Having a complete and verified backup before you begin the migration is essential. This will allow you to recover the server if anything goes wrong during the installation of Terminal Server.

3. Update and re-create a new Emergency Repair Disk. Launch the Repair Disk Utility from the command line by running rdisk. Remember to update your repair information before you create the Repair Disk, or you could lose user and application information. Migrating from WinFrame 1.6 or 1.7 to Terminal Server will preserve your users, network security, and applications.

4. Prepare the partition for upgrade. Verify that sufficient free space exists to copy the Terminal Server installation files and choose the correct partition when you upgrade. Terminal Server install will detect WinFrame installations and offer to upgrade them.

5. If your WinFrame system was using FAT, upgrade the file system to NTFS, which provides greater security in a multi-user environment in which users must have simultaneous access to the same resources. You must use NTFS on Terminal Server for security purposes. If you do not use NTFS on your migrated system, additional multi-user issues will occur that did not occur under WinFrame (for example, everyone having access to all the files in the Recycle Bin).

6. Upgrading WinFrame to Terminal Server will enable only client connectivity using RDP that ships with the Terminal Server product and is only available to run on Windows-based client devices (Windows 95 or 98, Windows NT 3.5x, and Windows for Workgroups 3.11) as well as RDP-based, Windows-based terminals. Maintaining support for ICA requires using the Citrix MetaFrame product. To use RDP, all clients devices will require installation of the appropriate 16- or 32-bit Windows-based Terminal Server client software that is included on the Terminal Server CD-ROM in the directory \clients\tsclient\win16 (for the 16-bit client) and \clients\tsclient\win32 (for the 32-bit client). For customers migrating from ICA to RDP, be aware that devices running MS-DOS, Windows 3.1, UNIX, Macintosh, and ICA-based, Windows-based terminals will only be supported running ICA and will consequently require the MetaFrame add-on.

RDP is only supported on TCP/IP networks. When upgrading to Terminal Server over non–TCP/IP-based networks (that is, the segment over which the display protocol will be transmitted) MetaFrame is also required.

Reviewing the Risk Assessment

Re-examining Risks

Risk identification and mitigation continue to be important functions and will remain so throughout the project. You can use the information you gathered while assessing the current environment and designing the deployment to identify additional risks or to revise existing ones.

Review the high-level risk assessment done earlier and update it if new information becomes available. Risk assessment should continue to influence how tasks are approached and the order in which they are addressed and managed.

Using an Assessment Matrix

You should maintain the risk assessment—which is best handled through a risk assessment matrix—as a living document that is updated whenever risks change (at least weekly, but perhaps more often, as necessary). The matrix should be included in deployment status reports.

For more detailed information about continued risk assessments, refer to Sample Risk Assessment Matrix in the Resources Included in self-extracting file Tsdeploy.exe as Sample Risk Assessment Matrix.doc).

Building and Approving the Master Project Plan

Building the Master Project Plan

All members of the project team contribute to the project plan by producing planning and scheduling documents describing how they will create the system or service as defined in the functional specification.

The project plan includes approach, dependencies, assumptions, and budget information and, in effect, refines the agreement of the vision/scope document between the team and the customer.

A good project plan:

• Is derived from the overall business objectives, user classes, and the activities each user class expects to perform.

• Categorizes customer requirements into three logical services: user, business, and data. These services are collectively called the logical architecture.

• Clearly defines the visual design, functional interfaces, data requirements, help systems and training, and rollout programs.

• Includes plans from each functional role. The testers will submit a test plan, the developers will submit a development plan, and so forth.

• Defines external interfaces, interoperability goals, performance goals, and other assumptions and constraints that bind the solution approach.

• Reflects the consensus and commitment of all team members.

• Drives scheduling internally and communication externally.

Approving the Master Project Plan

Checking the Deliverables

The project team should have a number of major deliverables ready before the project plan is completed and the Project Plan Approved Milestone is reached. These major deliverables include:

• The environment analysis should contain a comprehensive assessment of the technical infrastructure as it currently exists.

• The functional specification should provide the beginning of the deployment plan.

• The logical design should define the course of action necessary to achieve the business drivers.

• The physical design should detail the actual plan of action categorized into functional areas.

• The risk assessment should be updated with information gathered in this phase of deployment.

Updating the Project Plan

After the team has created the master project plan and started the project, they should update the data on a regular basis. The deployment team should review the project plan weekly or biweekly to determine of the project is on time and on budget.

Gaining Approval the Plan

As with the vision/scope document, the team should convene signatories, obtain sign-offs, and archive the project plan as a company document.

Scope Complete/First Use Milestone

Overview

Implementing the Pilot Stage

The goal of the Scope Complete/First Use Milestone is to test Terminal Server in a controlled environment and to begin the deployment process by installing a pilot server into a group engaged in real-world activity.

Activities, Resources, and Deliverables

The following table lists planning activities, their resources, and their associated deliverables.

Activity	Resource	Deliverable
Validating the plan	Information in text	Test lab built and Terminal Server tested
Developing a pilot implementation plan	Information in text	Pilot implementation plan
Deploying the pilot server	Information in text	Server deployed in pilot environment
Deploying applications on the pilot server	Information in text	Applications deployed on the server
Piloting Terminal Server	Information in text	Pilot users using Terminal Server
Assessing the pilot deployment	Sample Pilot Deployment Assessment Included in self-extracting file Tsdeploy.exe as Sample Pilot Assessment.doc	Pilot deployment assessment

Validating the Plan

Building and Configuring the Test Lab

After the team has developed a comprehensive deployment plan, they must validate the plan before the pilot deployment. Validation allows the team to test its assumptions and identify any problems before they manifest themselves in a working deployment. Failure to properly validate the plan could lead to costly mistakes or could inhibit critical tasks.

The ideal environment for validating a Terminal Server deployment is a test laboratory that has been constructed to simulate the environment of the actual deployment as closely as possible. The test lab will function as a miniature version of the organization itself, enabling the team to see Terminal Server in action before deployment.

To this end, consider several important items when building a test lab.

• Emulate the production environment as closely as possible. Use a server computer from the same vendor and with the same configuration as the servers that will be used in the actual deployment, and set up a representation of client workstations that will be using Terminal Server throughout the organization.

• Duplicate the organization's network configuration. If the network uses both Ethernet and Token Ring, you should have both in the test lab. If possible, set up a separate Windows NT Server domain for the lab so you can monitor the performance of the domain controllers without having to factor in other activity on the network. If you are planning to deploy Terminal Server on a WAN, design your lab with routers and use a link simulator to simulate network latency.

• If different divisions will be using Terminal Server in similar but non-identical ways, you can probably emulate all divisions within a single test lab. If the difference is significant enough, however, you might want to consider building a separate lab for each division or set of tasks.

  Different divisions within Rent-a-car, Inc., planned to use Terminal Server in different ways. Some divisions would use legacy personal computer equipment to run standard office applications, whereas others would use Windows-based terminals to gain access to database systems or use Terminal Server over dial-up lines. The deployment team identified three different user scenarios and constructed separate test labs to accommodate all three.

• Deploy a typical set of applications together on the test server. This step is vital in determining any interoperability issues that might arise when users run different applications simultaneously.

Using the Test Lab

After the test lab has been established, the deployment team can begin testing Terminal Server and the applications. Testers should focus on component testing, in which individual features or applications are evaluated, and integration testing, in which different applications and components are run together to determine how well they work with each other. Results from the test lab will also allow the team to establish a performance baseline for production use. It's important to test each application with at least two or three simultaneous users to reveal any issues that manifest only when multiple users run an application.

Typically, the deployment team itself will do most server and application testing in the test lab. The testers should be thoroughly familiar with the applications being deployed on Terminal Server so that they will be able to recognize performance issues easily and identify areas in which the applications must be optimized. It is sometimes appropriate to bring one or two real-world users in after the team has installed and tested the applications, especially when installing custom or specialty applications with which the team is unfamiliar.

If the team will be testing any custom applications, it's a good idea to locate the application developers, if possible, and keep them on call to answer any questions about configuration or to make modifications if necessary.

During application testing, you might encounter situations where you must change applications, scripts, registry keys, or other parts of the system. Carefully document all changes you make so you can reproduce them during the actual deployment.

Maintaining the Test Lab

The utility of the test lab does not end with the deployment. If possible, make plans to keep the lab intact indefinitely after completion of the full Terminal Server deployment to function as a staging area for new software. Having an isolated server or servers to test new hardware or software in a multi-user environment minimizes the risk of deploying untested equipment. The test lab also adds redundancy to the Terminal Server environment by providing hardware or servers that can be used to quickly and temporarily replace defective equipment in an emergency.

Developing a Pilot Implementation Plan

Identifying the Pilot Group

The first part of any pilot deployment is to identify the group of users who will be involved in the process.

The ideal pilot group should be smaller than other groups in the organization. The group should have enough users to adequately pilot Terminal Server and the applications, but a small group limits risk and exposure.

As with the test lab, the pilot group should have an infrastructure that is typical of the eventual Terminal Server environment as a whole. Try to choose a group that is up to date structurally. For example, do not pilot in a group that connects to the network using asynchronous transfer mode (ATM) if most of the users who will eventually use Terminal Server connect using a dial-up connection or other slow-speed link.

Select a group where deployment of Terminal Server will show a tangible improvement or benefit. Do not choose a group that relies on technology that will not function well under Terminal Server. For example, a group that makes extensive use of graphics-intensive tools like AutoCAD would not be an ideal choice.

The users should possess a relatively high level of technical expertise so they will be better able to understand and report issues and describe how to reproduce them. They should be receptive to the idea of working with new technology and be able to provide useful feedback and tolerate some initial challenges.

Choose a group with a good communication infrastructure in place to facilitate the exchange of information among group members and with the deployment team. Choose a champion to be the single point of contact within the group.

Avoid choosing a group engaged in mission-critical work that will be disrupted if Terminal Server fails or cannot handle the demands placed on it. For example, an accounting department that manages its books at the end of the month might be an ideal pilot group if the piloting process begins early in the month.

When the team deploying Terminal Server at Rent-a-Car, Inc., needed to find a pilot group, they chose the group within the procurement division concerned with purchasing new rental cars for the coming years. Because RACI almost always buys new cars during the fall and winter when automakers release new models, the group would not be engaged in mission-critical work during the spring, when the pilot process was planned. Furthermore, the group was found to be fairly typical of the company as a whole in terms of existing technology and infrastructure, and the employees used computers and business applications frequently in the course of their work and were generally receptive to the idea of moving to a new system.

The computers in the automobile procurement subdivision are a mixture of 486s running at 66 MHz and Pentiums running at 75 or 90 MHz. These computers currently use Windows for Workgroups 3.11 and older versions of business applications such as Word and Excel for Windows, plus a number of custom applications for tracking purchases and interfacing with an SQL database. The deployment team will install Microsoft Office 97 on the pilot server to replace the older versions of Word and Excel.

Developing Communication

Good group communication is a vital part of a successful pilot deployment. Before deployment begins, establish the communication framework you will be using. How and how often will the deployment team communicate information to the pilot group and vice versa? Will information be exchanged by voice mail, e-mail, an intranet Web site, paper, or another method? Consider setting up an internal Web site that the deployment team can use to post information for the pilot group.

Will the deployment team use a database to track and resolve issues raised by the pilot group? If the team will use a Web site to communicate with users, is it feasible to create a form that will allow users to post descriptions of issues themselves?

If the users have questions or issues with Windows NT or with the applications they will be using, do you want them to consult the deployment team or the organization's help desk, if one exists? If users will be sent to the help desk first, you should contact the help desk personnel and negotiate procedures that will enable them to determine when pilot users' issues should be referred back to the deployment team.

Deploying the Pilot Server

Preparing the Server

The first task in the pilot deployment involves preparing the server that you will use.

Before installing the pilot server in its final location, it's a good idea to put it though a burn-in period in the test lab. During this period, install the operating system and test the server thoroughly for issues with the hardware or software. By properly preparing the server in an isolated location, you can make final server installation as problem-free as possible and assure the users of the server's stability.

Preparing and installing Terminal Server is similar in many ways to deploying any other edition of Windows NT Server 4.0. Mechanisms available to assist deployment include:

• An unattended setup script that uses a text file called Unattend.txt to automate the Terminal Server automation process.

  The Unattend.txt file for Terminal Server supports the same level of automation as Windows NT Server and also lets you specify the number of Terminal Server desktop licenses and whether to install Internet Explorer as a part of the unattended setup using the following variables:

[TerminalServerDesktops] Quantity = <number of licenses> [InternetExplorer] InstallIE4 = <yes or no>

![tsdep03](images/Cc751285.tsdep03(en-us,TechNet.10).gif "tsdep03")

For a sample file, see *Sample Unattend.txt* in the Resources section (Included in self-extracting file Tsdeploy.exe as Sample unattend.txt).

• Sysdiff, a utility included with the Terminal Server distribution, that allows you to pre-install applications simultaneously with the operating system by allowing system administrators to create package files that can be applied to a system during installation. Sysdiff provides tools for creating and applying system difference files, generating installation .inf files, and establishing distribution sharepoints.

• Select and configure the server. Using the physical design as a guide to hardware and software requirements, select and configure the server to be used.

  As with the test lab, use a server computer from the same vendor and with the same configuration as the servers you will be using in the full deployment. Hardware standards make it easier to deploy and support Terminal Server and to negotiate a better price from the vendor. In addition, it is easier to repair or replace faulty servers or to test new applications and cards.

• Install the software. Install the Terminal Server software on the server as you would install any other version of Windows NT. Consult the Terminal Server documentation for specific installation instructions.

• Create user accounts. This will generally be necessary only if the server has not been installed as part of a domain. If you will be adding Terminal Server–specific attributes to user accounts and are concerned about the size of the SAM on the domain controller, consider making the server running Terminal Server a stand-alone server and creating accounts for the users.

• Set file and user permissions. Set permissions as needed to secure the pilot environment. You need not provide the pilot users with permissions beyond those they would have as typical users because the purpose of the piloting stage is to emulate the full deployment on a smaller scale.

• Set file shares. Create any file and directory shares you know you'll need, and give the users access to them as appropriate.

• Set up printers. Set up and configure any printers you want available to the pilot users.

For a checklist to use when installing and configuring the pilot server, see Terminal Server Deployment Checklist in the Resources Included in self-extracting file Tsdeploy.exe as Deployment Checklist.doc).

Installing the Terminal Server Client

After installing and configuring the server, the next step is to install the Terminal Server Client application on users' computers.

Windows CE–based terminals come with Terminal Server Client preinstalled, so no installation will be necessary. If any terminals in the pilot group use the ICA protocol only, you must install MetaFrame from Citrix Systems on Terminal Server before the ICA terminals can connect.

Administrators and users can install the client software on Windows-based personal computers in a number of ways.

• The software can be installed manually from a floppy disk. Terminal Server Client and related files take up about 500 KB when installed.

• The software can be installed over the network by copying the installer program to the local personal computer from a shared network disk drive. The deployment team can also e-mail the users a shortcut to the installer program on a publicly accessible share point.

Terminal Server Client can be installed "quietly" (suppressing all or part of the installer program's user interface) from the command prompt by using one of the switches shown in the following table.

Terminal Server Client Quiet Installation

Syntax	Description	Availability
SETUP /Q	Installs quietly without prompting for information and shows the exit dialog box.	Windows for Workgroups 3.11, Windows 95 or 98, and Windows NT 3.5 or greater
SETUP /Q1	Installs quietly without prompting for information and hides the exit dialog box.	Windows for Workgroups 3.11, Windows 95 or 98, and Windows NT 3.5 or greater
SETUP /QT	Installs quietly, suppressing the entire installer user interface, including the blue background and copy gauge.	Windows 95 or 98 and Windows NT 3.5 or greater

Users connect to a specific server running Terminal Server by launching Terminal Server client and entering the server's name in the Server text field, or choosing a server from the Available Servers list. Available Servers lists only those servers in the domain running Terminal Server to which the client computer belongs, so the deployment team must supply users with the exact spelling of the name of the server running Terminal Server if it has been deployed in a different domain. Selecting the Low Speed Connection check box improves performance across a slow link by enabling compression on the server side.

The installer will create two applications on the user's personal computer called Terminal Server Client and Client Connection Manager. Users can use Client Connection Manager to set up shortcuts to frequently used servers running Terminal Server by clicking New from the File menu and entering the name of the server running Terminal Server and a name for the shortcut. This creates a shortcut in the Terminal Server program group that can be activated on the Start menu.

Administrators can configure Client Connection Manager to install a predefined set of shortcuts and distribute them to the users before installation. The administrator configures Terminal Server Client as appropriate and exports the configuration to a file of type .cns. When a user copies the .cns file to the directory containing the Terminal Server Client Setup program and then installs the client, the settings will be identical to those in the .cns file.

The administrator should never configure a username and password before creating and distributing the .cns file. This will allow other users to log on to Terminal Server with the username distributed in the file.

After connecting to a server running Terminal Server, users simply type their user name and password and choose a domain (if required), just as if they were logging on to any other computer running Windows NT.

If mandatory profiles are not used, users will find that logging on to Terminal Server and launching applications for the first time take longer than usual because the system configures applications for first use. For this reason, consider staggering deployment of Terminal Server Client so that all users don't overwhelm the system by logging on at once. Even if you've planned to support a certain number of concurrent users, the system can still suffer if all of those users are performing configuration and initialization tasks at the same time.

Deploying Applications on the Pilot Server

Installing Applications

The final step in preparing the pilot Terminal Server for use is to install and test the applications that will be used. This should include not only the specific applications you know the pilot users will need, but also any other application or utility software that will reside on a typical Terminal Server. This will help flush out any additional application interoperability issues that were not uncovered in the test lab.

Testing Applications

You should test applications before giving pilot users access to them. Some applications require modification to run optimally in the Terminal Server environment or have a negative impact on performance. Remember that applications that run poorly under Terminal Server can negatively affect all system users. You should deploy only applications that have been adequately tested.

Test all vendor and custom applications for compatibility with Terminal Server after installing them on the pilot server.

Two common ways an application might fail in a Terminal Server environment are:

• The application fails to run entirely or has clear problems that are evident upon application startup or within a few minutes of working with the applications. Problems of this sort can include a failure to redraw the screen correctly or a notification that the application cannot run a DLL or find a file.

• The application appears to run fine at first but manifests problems when two or more users run it simultaneously or attempt to set user-specific preferences. Problems of this nature will occur with applications that store a single set of user preferences in a global location and overwrite them when a separate user makes changes to the application environment. Another problem can occur when multiple users gain access to an application simultaneously but that application expects each user to have a unique IP address. An example would be a firewall that uses TCP/IP to enforce security. If the firewall is configured to grant access to the address of the server running Terminal Server, any users on that server will likewise have access through the firewall.

Determine which applications work under Terminal Server unmodified, which work with the supplied application compatibility scripts or other simple modifications, and which applications do not work at all. If possible, work with the author of custom-designed applications to fix any problems that manifest during application testing. Refer to Optimizing Applications for Windows NT Server 4.0, Terminal Server Edition in the Resources section (Included in self-extracting file Tsdeploy.exe as Optimizing Applications.doc) for guidelines in writing applications that are compatible with Terminal Server.

Piloting Terminal Server

Beginning Testing

After the servers and applications are in place, the pilot user group can begin working with Terminal Server.

If the deployment has been adequately planned and tested, you should experience little in the way of unexpected or catastrophic problems. Users who are familiar with Windows NT or the Win32 user interface will find that Terminal Server is intuitive and varies only slightly from other versions of Windows NT.

Communicating with Pilot Users

Communication between the pilot group and the deployment team is key. Provide the pilot users with frequent status updates and communicate with the group champion regularly, ideally once a day.

Measure the success of the pilot deployment by tracking user perception and ensuring that all outstanding issues are resolved satisfactorily.

Assessing the Pilot Deployment

Holding the Postmortem

The pilot deployment concludes with an assessment of the process produced by the deployment team with the assistance of the pilot group. This assessment is usually conducted in the form of a postmortem meeting.

Use this meeting to discuss such things as any help desk reports related to Terminal Server, technical issues or problems that came up during the process, and information related to the risks identified earlier in the deployment. Use this information to produce a report describing the pilot process that can be presented to the individuals at the organization responsible for overseeing the deployment of Terminal Server.

Recognizing a Successful Pilot

Characteristics of a successful pilot deployment include:

• End-user satisfaction as indicated by user feedback.

• A positive status report that the deployment group can present to management.

• Permission to continue with the full deployment.

• No major, unresolved application incompatibilities that prevented the pilot deployment from proceeding as planned.

For an example of a pilot deployment assessment, see Sample Pilot Deployment Assessment in the Resources Included in self-extracting file Tsdeploy.exe as Sample Pilot Assessment.doc).

Release Milestone

Overview

Completing the Deployment

The goal of the Release Milestone is to use the knowledge gained in the other three milestones to complete the deployment of Terminal Server throughout the organization and to prepare the infrastructure for ongoing maintenance and support.

Activities, Resources, and Deliverables

The following table lists planning activities, their resources, and their associated deliverables.

Activity	Resource	Deliverable
Deploying Terminal Server throughout the environment	Information in text	Terminal Server deployed throughout environment
Assessing the complete deployment	Sample Deployment Assessment Included in self-extracting file Tsdeploy.exe as Sample Deployment Assessment.doc	Deployment assessment
Planning ongoing maintenance, support, and scalability	Information in text	A stable, scalable Terminal Server infrastructure

Deploying Terminal Server Throughout the Environment

Deploying Servers and Clients

Having completed the pilot process, you have experience deploying Terminal Server within the organization and are prepared to move to a full-scale deployment.

For the most part, the full deployment process resembles the pilot deployment process, but on a larger scale. However, the team will have certain tools that can help it take advantage of economies of scale to aid in deploying Terminal Server quickly and efficiently.

One approach is to use a mechanism like the Microsoft Windows NT System Preparation Tool to reproduce the disk image from a master server to a number of other servers. The goal of this approach is to create a master image that includes the operating system, application, and other Terminal Server settings and then duplicate this configuration on other server computers. This is one example of the benefits of buying a number of identical servers from the same vendor because this method is possible only with servers that have identical hardware configurations.

You should keep some important issues in mind when deploying cloned servers. One is that the local administrator account password will initially be the same for all Windows NT systems cloned from a given image, so it's important to immediately reset the administrator password on each computer.

Additionally, the Windows NT System Preparation Tool does not support modifying SIDs, so administrators should not create any accounts on a server running Terminal Server. Instead, they should use groups or accounts from the user account domain to assign permissions to the registry or local hard disk drive.

Finally, never use System Preparation Tool to replicate domain controllers because these controllers will not be able to establish trusts to other systems.

Training Users

Technicians who will be administering Terminal Server should be trained on Windows NT Server 4.0 and on Terminal Server specifically. Refer to the books and courses listed in the "Project Overview" section of this guide for training resources.

If the organization has its own help desk for users with computer-related problems, the help desk personnel should be trained to answer questions related to Terminal Server and to Windows NT if they haven't already received such training. Consider training a few help desk employees on Terminal Server administration to serve as a second tier of support to whom front line help desk personnel can refer questions specifically related to Terminal Server rather than to the Windows environment in general or to the applications used.

Plan to hold Windows training sessions for users who will be moving to Terminal Server from other computing platforms. These sessions don't necessarily have to be particularly detailed. Consider developing a video or brief self-study program or holding a lunch bag session.

Also plan to train users on any new applications that will be deployed on Terminal Server. The amount of training users need will vary depending on their level of experience and whether they have already worked with similar applications or earlier versions. Consider assembling a quick start guide or reference card for some applications.

The following table will help you determine how much training users and support personnel at different levels should have.

Training Required

Level of support	Recommended level of training
Users	Basic knowledge of Windows and a more extensive familiarity with relevant applications
Help desk (first tier)	Windows NT Administration (ATEC Class 803); trained to support applications
Advance support	MCSE with Terminal Server specialty; ATEC Class 1198

Assessing the Complete Deployment

Assuring Satisfaction

If you have planned the Terminal Server deployment project well and carried out the pilot deployment successfully, the full deployment should proceed with few unexpected surprises or problems.

During and after the deployment, communicate with the project overseers to report progress and gauge overall satisfaction. The result of a successful deployment will be a satisfied customer or management unit, the satisfactory achievement of all primary deployment goals, and a Terminal Server infrastructure that can be adequately maintained and scaled for the future.

Planning Ongoing Maintenance, Support, and Scalability

Maintaining Terminal Server

If you have kept the test lab running during the deployment, you can use the test servers as a staging platform for testing new applications and determining the ideal way to deploy them. You can also use the lab to test any significant changes you want to make to the server or network to ensure that the changes will not harm important data or mission-critical work.

If the organization does not have a Windows NT backup and tape rotation plan, establish one for Terminal Server. You can use a dedicated tape device for each Terminal Server or back up all servers over the network.

Always disconnect all users from Terminal Server and prevent inbound connections from being established before installing any new software intended for multiple users.

Never use regular Windows NT 4.0 service packs with Terminal Server. Microsoft will release service packs and patches dedicated to Terminal Server as needed. Applying service packs not approved for use with Terminal Server can severely damage the system. Certain option pack features may run successfully under Terminal Server; consult your Microsoft representative for additional information.

Planning for Capacity

Capacity planning is especially important when deploying Terminal Server, as computing power is relatively centralized and bottlenecks can have a significant performance impact for many users. See Capacity Planning and Performance Analysis in the Resources section (Included in self-extracting file Tsdeploy.exe as Capacity-Performance.doc) for more information.

Evaluating CPU Performance

Detecting a processor bottleneck in Terminal Server is similar to detecting processor bottlenecks in Windows NT Server and Workstation, but the baseline values for the counters may differ. The most significant counters for evaluating CPU performance are %Total Processor Time, Processor Queue Length, % Processor Time, Context Switches/Sec, and Total Interrupts/Sec.

• %Total Processor Time (System) is a measure of activity on all system processors. In a multiprocessor computer, this counter is equal to the total amount of processor activity divided by the number of processors. This counter is especially useful after it has been verified that all system processors are processing threads equally.

• Processor Queue Length (System) is the instantaneous length of the processor queue in units of threads. All processors use a single queue in which threads wait for processor cycles. After a processor is available for a thread waiting in the processor queue, the thread can be switched onto a processor for execution. A processor can execute only a single thread at a time. Previous observations of the processor queue length in Windows NT Server 4.0 indicated that a sustained processor queue length greater than two indicated processor congestion. As described below, testing has shown the Windows Terminal Server can sustain a processor queue length of 10 to 12 threads per processor and still provide acceptable performance. It is important to note that the processor queue length is an instantaneous count, not an average over the time interval.

• % Processor Time (Processor) is the percentage of time the processor was busy executing a thread other than the thread of the Idle process. This counter has an instance for each system processor available to the operating system. You can use it to verify that each system processor is contributing equally to processing waiting threads.

• Total Interrupts/Sec is the rate at which the computer is receiving and servicing hardware interrupts. Some devices that might generate interrupts are the system timer, the mouse, data communication lines, network interface cards, and other peripheral devices. You can use this counter to identify any device drivers that may be consuming an unusually high amount of processor time.

• % Total Processor Utilization and Processor Queue Length are the most significant counters for identifying bottlenecks in CPU bottlenecked systems. As the system processors become busier, the number of threads waiting for execution in the Processor Queue increases. Generally when the Average Processor Queue Length per processor exceeds 12 threads, the system is at the limit of acceptable performance. As the average Processor Queue Length per processor exceeded 12 to 15 threads in testing, the system was in the unacceptable performance range and delays were observed in the display of typed characters on client workstations.

Resources

Master List of Resources and Online Pointers

Resource Title/Description	Location on CD-ROM	Online Pointer or URL
Application Assessment Profile	Included in self-extracting file Tsdeploy.exe as Application Assessment.doc
Citrix Systems Web site		https://www.citrix.com
CrashOnAuditFail Activates on Shutdown with ProcessTracking	Included in self-extracting file Tsdeploy.exe as 149393 - Audit Log.doc
Do Not Display Last Logged-on User Name	Included in self-extracting file Tsdeploy.exe as 114463 - Last User Name.doc
Setting an Application Compatibility Flag to Avoid the Error "Duplicate NetBIOS Name in Use"	Included in self-extracting file Tsdeploy.exe as Duplicate NetBIOS Name.doc
Domain Calculation Model	Included in self-extracting file Tsdeploy.exe as Domain Calculation Model.xls
Excessive and Unnecessary Paging File Activity	Included in self-extracting file Tsdeploy.exe as 101041 - Paging File Activity.doc
How to Create a Base Profile for All Users	Included in self-extracting file Tsdeploy.exe as 168475 - Base Profile.doc
How to Create NT 4.0 Mandatory Profiles	Included in self-extracting file Tsdeploy.exe as 168476 - Mandatory Profiles.doc
How to Delete Cached Profiles	Included in self-extracting file Tsdeploy.exe as 173870 - Deleting Cached Profiles.doc
How to Disable Installation of NWLink NetBIOS	Included in self-extracting file Tsdeploy.exe as 156203 - NWLink NetBIOS.doc
How to Set Up Locally Based System Policies	Included in self-extracting file Tsdeploy.exe as 168579 - System Policies.doc
Implement Strong Passwords	Included in self-extracting file Tsdeploy.exe as 161990 - Strong Passwords.doc
Master List of Resources and Online Pointers	Included in self-extracting file Tsdeploy.exe as Reference \Master List.doc
Microsoft Certified Solution Providers		https://www.microsoft.com/mcsp/
Microsoft/Citrix Scalability and Performance White Paper		https://www.microsoft.com/ntserver
Microsoft Consulting Services information		https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise=portfolio=consulting
Microsoft Developer Network online		https://www.microsoft.com/msdn/
Microsoft KnowledgeBase		https://support.microsoft.com/default.aspx?scid=kb;en-us;185322&sd=tech
Microsoft partnering		https://members.microsoft.com/partner/default.aspx
Microsoft Press information	Included in self-extracting file Tsdeploy.exe as Microsoft Press.doc
Microsoft Press Web site		https://www.microsoft.com/mspress/
Microsoft Product Support Services and Technical Account Manager		https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise=consulting=supportservices
Microsoft Search Page		https://www.microsoft.com/Search
Microsoft Solutions Framework information		https://www.microsoft.com/trainingandservices/default.asp?PageID=enterprise=solutions
Microsoft support		https://www.microsoft.com/support/
Microsoft TechNet		https://www.microsoft.com/technet
Microsoft Web site		https://www.microsoft.com
Microsoft Windows NT Server and Terminal Server home page		https://www.microsoft.com/ntserver
Microsoft Windows NT Training Kits from Microsoft Press		https://www.microsoft.com/learning/books/certification
Modifying DOS Application Keyboard Polling Detection	Included in self-extracting file Tsdeploy.exe as DOS Keyboard Polling.doc
Modifying Ntuser.dat Hive so New Users Get Defined Settings	Included in self-extracting file Tsdeploy.exe as 146050 - Defined Settings.doc
Optimizing Applications for Windows NT Server 4.0, Terminal Server Edition	Included in self-extracting file Tsdeploy.exe as Optimizing Applications.doc
Performance Drops During Large File Copy	Included in self-extracting file Tsdeploy.exe as 110255 - Performance Drops.doc
Performance Tuning CPU Usage for 16-bit and 32-bit Windows Applications	Included in self-extracting file Tsdeploy.exe as Performance Tuning CPU Usage.doc
Guide to Microsoft Windows NT 4.0 Profiles and Policies	Included in self-extracting file Tsdeploy.exe as Policies vs Profiles.doc
Project (template)	Included in self-extracting file Tsdeploy.exe as Project Plan.mpp
Sample Agenda for Vision/Scope Approval Meeting	Included in self-extracting file Tsdeploy.exe as Sample Agenda.doc.
Sample Deployment Assessment	Included in self-extracting file Tsdeploy.exe as Sample Deployment Assessment.doc
Sample Environment Assessment	Included in self-extracting file Tsdeploy.exe as Sample Environment Assessment.doc
Sample Logical Design	Included in self-extracting file Tsdeploy.exe as Sample Logical Design.doc
Sample Physical Design	Included in self-extracting file Tsdeploy.exe as Sample Physical Design.doc
Sample Pilot Assessment	Included in self-extracting file Tsdeploy.exe as Sample Pilot Assessment.doc
Sample Risk Assessment Matrix	Included in self-extracting file Tsdeploy.exe as Sample Risk Assessment Matrix.doc
Sample Security Configuration	Included in self-extracting file Tsdeploy.exe as Sample Security Configuration.doc
Sample unattend.txt	Included in self-extracting file Tsdeploy.exe as Sample unattend.txt
Setting Primary and Secondary WINS Server Options	Included in self-extracting file Tsdeploy.exe as 150737 - WINS Servers.doc
Terminal Server Deployment Checklist	Included in self-extracting file Tsdeploy.exe as Deployment Checklist
Terminal Server Deployment Flowchart	Included in self-extracting file Tsdeploy.exe as Flowchart.vsd
Using DNS to Simulate Load Balancing with Microsoft Windows NT Server 4.0 – Terminal Server Edition	Included in self-extracting file Tsdeploy.exe as DNS Load Balancing.doc
Vision/Scope Document	Included in self-extracting file Tsdeploy.exe as Sample Vision-Scope.doc
ZAK for Terminal Server	D Included in self-extracting file Tsdeploy.exe as ZAKforTS v2.1.doc

Macintosh is a registered trademark of Apple Computer, Inc.