tm

The Definitive Guide To

Windows Server 2003

Terminal Services

Gresyon Mitchem
 Introduction

Introduction

By Sean Daily, Series Editor

Welcome to The Definitive Guide to Windows Server 2003 Terminal Services!

The book you are about to read represents an entirely new modality of book publishing and a
major first in the publishing industry. The founding concept behind Realtimepublishers.com is
the idea of providing readers with high-quality books about today’s most critical IT topics—at no
cost to the reader. Although this may sound like a somewhat impossible feat to achieve, it is
made possible through the vision and generosity of corporate sponsors such as triCerat, who
agree to bear the book’s production expenses and host the book on its Web site for the benefit of
its Web site visitors.
It should be pointed out that the free nature of these books does not in any way diminish their
quality. Without reservation, I can tell you that this book is the equivalent of any similar printed
book you might find at your local bookstore (with the notable exception that it won’t cost you
$30 to $80). In addition to the free nature of the books, this publishing model provides other
significant benefits. For example, the electronic nature of this eBook makes events such as
chapter updates and additions, or the release of a new edition of the book possible to achieve in a
far shorter timeframe than is possible with printed books. Because we publish our titles in “real-
time”—that is, as chapters are written or revised by the author—you benefit from receiving the
information immediately rather than having to wait months or years to receive a complete
product.
Finally, I’d like to note that although it is true that the sponsor’s Web site is the exclusive online
location of the book, this book is by no means a paid advertisement. Realtimepublishers is an
independent publishing company and maintains, by written agreement with the sponsor, 100%
editorial control over the content of our titles. However, by hosting this information, triCerat has
set itself apart from its competitors by providing real value to its customers and transforming its
site into a true technical resource library—not just a place to learn about its company and
products. It is my opinion that this system of content delivery is not only of immeasurable value
to readers, but represents the future of book publishing.
As series editor, it is my raison d’être to locate and work only with the industry’s leading authors
and editors, and publish books that help IT personnel, IT managers, and users to do their
everyday jobs. To that end, I encourage and welcome your feedback on this or any other book in
the Realtimepublishers.com series. If you would like to submit a comment, question, or
suggestion, please do so by sending an email to feedback@realtimepublishers.com, leaving
feedback on our Web site at www.realtimepublishers.com, or calling us at (707) 539-5280.

Thanks for reading, and enjoy!

Sean Daily
Series Editor

i
 Table of Contents

Introduction...................................................................................................................................... i
Chapter 1: Introduction to Windows Server 2003 Terminal Services.............................................1
Server Roles .....................................................................................................................................1
File Server............................................................................................................................3
Print Server ..........................................................................................................................3
Application Server ...............................................................................................................3
Mail Server...........................................................................................................................4
Terminal Server ...................................................................................................................4
Remote Access/VPN Server ................................................................................................4
Domain Controller ...............................................................................................................4
DNS Server ..........................................................................................................................5
DHCP Server .......................................................................................................................5
Streaming Media Server ......................................................................................................5
WINS Server........................................................................................................................5
Terminal Services Technology ........................................................................................................6
New Answers for Old Challenges....................................................................................................7
Remote Desktop...................................................................................................................7
Compatibility Modes ...........................................................................................................8
RDP 5.2 Protocol Enhancements.........................................................................................9
Remote Desktop Connection Client.......................................................................10
Group Policy–Based Configuration...................................................................................11
ADSI Access to User Parameters ......................................................................................11
Session Directory ...............................................................................................................12
Terminal Services Licensing..........................................................................................................12
Terminal Server Licensing Components ...........................................................................12
License Types ....................................................................................................................13
Installing Terminal Server Licensing.................................................................................14
License Server Discovery ..................................................................................................17
License Assignment ...........................................................................................................19
License Server Administration ..........................................................................................20
License Server Group Policy Settings ...............................................................................21
Summary ........................................................................................................................................22
Chapter 2: Installing and Configuring the Terminal Server Role..................................................23

ii
 Table of Contents

Terminal Services Deployment Scenarios .....................................................................................23

Desktop Replacement ........................................................................................................24
Remote Access...................................................................................................................25
ASP ....................................................................................................................................26
Installing the Terminal Server Role...............................................................................................26
Configuring the Terminal Server Role ..........................................................................................30
Terminal Services Configuration Administrative Tool .....................................................30
Permission Compatibility.......................................................................................31
Licensing................................................................................................................32
Restrict Each User to One Setting .........................................................................32
Group Policy–Based Configuration...................................................................................37
Additional Configuration Settings .....................................................................................39
Installing and Configuring the Remote Desktop Connection Client .............................................41
Remote Desktop Connection Client...................................................................................41
Remote Desktop Web Connection.....................................................................................43
Remote Desktops Administrative Tool..............................................................................44
Summary ........................................................................................................................................45
Chapter 3: Load Balancing and Session Directory ........................................................................46
Terminal Server Hardware Configuration .....................................................................................46
Hard Disk Configuration....................................................................................................47
Memory..............................................................................................................................50
Processor ............................................................................................................................51
The Bottom Line ................................................................................................................53
Fault Tolerance ..............................................................................................................................53
Load Balancing ..............................................................................................................................55
Microsoft Network Load Balancing ..................................................................................55
Configuring NLB ...................................................................................................56
Third-Party Load Balancers...............................................................................................62
Session Directory ...........................................................................................................................62
Configuring Session Directory ..........................................................................................63
How Session Directory Works...........................................................................................65
Summary ........................................................................................................................................67
Chapter 4: Terminal Services Administration ...............................................................................68

iii
 Table of Contents

Terminal Server Access Requirements..........................................................................................68

Allow Log On Through Terminal Services .......................................................................68
Permissions on RDP ..........................................................................................................69
RDP Access Levels................................................................................................70
Allow Logon to Terminal Server.......................................................................................72
User Account Configuration ..........................................................................................................73
Home and Profile Directories ............................................................................................75
Terminal Services Profile Path ..............................................................................75
Terminal Services Home Directories.................................................................................77
Configuring User Properties Through the Active Directory Service Interfaces................77
Group Policy Overrides of User Settings...........................................................................79
Managing Terminal Servers in an AD Environment .....................................................................80
Active Directory Users and Computers .............................................................................81
Group Policy Management Console ..................................................................................82
Configuring Terminal Servers with GPOs.........................................................................83
UI Settings .............................................................................................................83
Restricted Groups...................................................................................................86
Standard Group Policy Processing Order ..............................................................86
Loopback Group Policy Processing Order ............................................................88
Enabling Loopback ............................................................................................................90
Resultant Set of Policy...........................................................................................91
Managing User Sessions ................................................................................................................91
Terminal Services Manager ...............................................................................................92
Remote Control..................................................................................................................94
Registry Editing .................................................................................................................95
Command-Line Utilities ....................................................................................................96
Summary ........................................................................................................................................96
Chapter 5: Application Installation and Compatibility..................................................................97
Application Compatibility Mechanisms ........................................................................................97
Terminal Services Logon Scripts.......................................................................................98
USRLOGON.CMD................................................................................................99
Additional Administrative Scripts ...................................................................................103
Application Installation................................................................................................................104

iv
 Table of Contents

Registry Mapping.............................................................................................................104
INI File Mapping .............................................................................................................106
Install and Execute Modes ...............................................................................................106
Application Compatibility Scripts ...................................................................................107
Examples of Terminal Services Application Installations...............................................108
Simple Installation ...............................................................................................109
Custom Installation ..............................................................................................110
Application Compatibility Script Installation......................................................114
Installing Undocumented Applications............................................................................115
A Real World Example........................................................................................117
Terminal Services Compatibility Flags ...........................................................................121
Installing Applications Through Group Policy............................................................................122
Create a Share ..................................................................................................................122
Create Administrative Installations..................................................................................122
Add the Packages to a GPO .............................................................................................123
Filtering Applications ......................................................................................................124
Reboot the Terminal Servers ...........................................................................................126
Deploying Applications to End Users..........................................................................................127
Summary ......................................................................................................................................127
Chapter 6: Managing Security and Virus Protection ...................................................................128
Viruses, Worms, and Trojan Horses…Oh My! ...........................................................................128
Internet Explorer Enhanced Security Configuration....................................................................129
Changes Made by Internet Explorer Enhanced Security Configuration..........................131
Managing Approved ActiveX Controls ...........................................................................133
Implementing Windows Automatic Updates...............................................................................134
Using SUS....................................................................................................................................137
Deploying Service Packs and Hotfixes........................................................................................142
Using Group Policy to Deploy Service Packs .................................................................142
Deploying Hotfixes..........................................................................................................143
Using a ZAP File .................................................................................................144
Using a Shutdown Script .....................................................................................145
Virus Protection Software Best Practices ....................................................................................147
Putting It All Together .................................................................................................................147

v
 Table of Contents

Example One: Anytown Little Theatre............................................................................147

Example Two: BigBusiness, Inc......................................................................................148
Summary ......................................................................................................................................150
Appendix A: Terminal Services Clients ......................................................................................151
Appendix B: Important URLs......................................................................................................152
Appendix C: Registry Changes....................................................................................................153
Appendix D: Script Reference .....................................................................................................154
USRLOGON.CMD......................................................................................................................154
TSSHUTDN Wrapper..................................................................................................................156
Maintenance Reboot Script..........................................................................................................158
Appendix E: Terminal Services Command Line Reference........................................................160
Change Logon......................................................................................................160
Query Terminal Servers.......................................................................................160
Query Session ......................................................................................................161
Query User ...........................................................................................................161
Query Process ......................................................................................................162
Logoff ..................................................................................................................162
Message................................................................................................................163
Reset Session .......................................................................................................163
Shadow.................................................................................................................164
Terminal Services Profile ....................................................................................164
Terminal Server Shutdown ..................................................................................165
Remote Desktop Client Command Line Parameters: ..........................................165

vi
 Copyright Statement

Copyright Statement
© 2003 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that
have been created, developed, or commissioned by, and published with the permission
of, Realtimepublishers.com, Inc. (the “Materials”) and this site and any such Materials are
protected by international copyright and trademark laws.
THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
and do not represent a commitment on the part of Realtimepublishers.com, Inc or its web
site sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors be
held liable for technical or editorial errors or omissions contained in the Materials,
including without limitation, for any direct, indirect, incidental, special, exemplary or
consequential damages whatsoever resulting from the use of any information contained
in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not
be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
way, in whole or in part, except that one copy may be downloaded for your personal, non-
commercial use on a single computer. In connection with such use, you may not modify
or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of
third parties. You are not permitted to use these trademarks, services marks or logos
without prior written consent of such third parties.
Realtimepublishers.com and the Realtimepublishers logo are registered in the US Patent
& Trademark Office. All other product or service names are the property of their
respective owners.
If you have any questions about these terms, or if you would like information about
licensing materials from Realtimepublishers.com, please contact us via e-mail at
info@realtimepublishers.com.

vii
 Chapter 1

Chapter 1: Introduction to Windows Server 2003 Terminal

Services
With the launch of Windows Server 2003 (WS2K3), Microsoft has continued to improve upon
Terminal Services. At the launch event, Microsoft focused on the fact that this version of
Windows is the most customer driven to date. Terminal Services’ new features clearly
demonstrate this focus—there are certainly several enhancements that I have been hoping for.
In this book, I will introduce you to the new features and enhancements in WS2K3 Terminal
Services. I will also discuss best practices for configuring and managing Terminal Services with
an eye to the new techniques available to systems administrators in WS2K3. As we’ll explore,
with Remote Desktop Protocol (RDP) 5.2, Active Directory Service Interfaces (ADSI) access to
Terminal Services attributes of user objects, new Group Policy Object (GPO) controls, and
Session Directory, we now have the ability to use native Terminal Services as an enterprise-class
solution for providing users with Terminal Services–based desktops.

Server Roles
When you install WS2K3, most non-critical subsystems and services are disabled or not
installed. The reason for this default configuration is Microsoft’s new focus on security. Because
the system is secure by default, systems administrators can focus on designing systems that
perform only desired functions and not worry about server hardening as much. To help enable
desired functions, Windows now offers Server Roles, as Figure 1.1 shows.

Figure 1.1: The Manage Your Server wizard.

1
 Chapter 1

A role is a server function (for example, mail server, domain controller). A single server can
perform more than one role if desired, enabling you to do more with less—the slogan for
WS2K3. When an administrator logs on to a server, the Manage Your Server wizard offers to
assist in adding new roles and managing currently installed roles.
When adding a new role, the Manage Your Server wizard enables services and performs any
security changes required by the role. You can still add and remove services the old-fashioned
way through the Add/Remove Windows Components and Services Control Panel applet, but I
find that the Manage Your Server Wizard is very useful. (The useable wizard in WS2K3 is quite
a change from the one in Windows 2000—Win2K; most of us disabled the Win2K Configure
Your Server wizard at first boot.)
After you add a role, the Manage Your Server wizard provides easy access links to common
tools and settings used for each role. Figure 1.2 shows the default roles available in WS2K3
Standard Edition.

Figure 1.2: Default roles available in WS2K3 Standard Edition.

2
 Chapter 1

File Server
Adding the file server role optimizes the server for network shares and file storage. After adding
the file server role, you will be able to set disk space quotas for users, use the indexing service to
search for files, and even search for documents in different formats and languages by using the
Start menu’s Search tool or a new Web-based search interface. WS2K3 offers many new features
to improve file serving:
• Shadow copy—Maintains byte-level backups of previous versions of documents to allow
end users to undo changes made to documents stored on the server.
• Enhanced Distributed File System (DFS)—Lets you create a single logical namespace for
multiple shares spanning servers across the enterprise. This functionality keeps your end
users from having to memorize the server names for shares they frequently use. WS2K3’s
DFS also provides a robust file replication service with topology choices not available in
Win2K. In addition, WS2K3 servers can host more than one DFS root.
• Volume shadow copy service—Creates a point-in-time copy of the original data share.
Backup programs can use this copy to make a share appear static while the actual
documents are changing. In addition, you can move shadow copies to other servers for
backup, testing, and data mining.

Print Server
Print servers are used to provide and manage access to printers. The print server role lets you
manage printers through a Web browser, send print jobs to a printer’s URL using the Internet
Printing Protocol (IPP), and connect to printers using Point and Print. Microsoft has made
several enhancements to printing services in WS2K3:
• Print cluster support—Automatically replicates printer drivers to all servers in the cluster
• Active Directory (AD) enhancements—Lets administrators publish printers in AD so that
users can search for printers based on location, color, and speed
• Security enhancements—Includes new Group Policies that let administrators prevent
managed clients from connecting to untrusted print cues and prevent connections to the
print spooler if the server is not providing print services

Application Server
When you configure a server to be an application server, you are installing Internet Information
Services (IIS) 6.0 as well as several optional technologies and services such as COM+ and
ASP.NET. Microsoft has optimized IIS 6.0 for Web server reliability, server management and
consolidation, faster application development, and increased security.

3
 Chapter 1

WS2K3’s application server role provides support for new Web services and the .NET platform,
including enterprise Universal Description, Discovery, and Integration (UDDI) services as well
as Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL).
Application servers are often configured to include:
• Resource pooling
• Distributed transaction management
• Integrated security
• Failover and application health detection services

Mail Server
WS2K3 now offers a Post Office Protocol 3 (POP3) and Simple Mail Transfer Protocol (SMTP)
server option. This option lets you manage basic email accounts for your users and enables users
to send and retrieve mail from the server. Mail servers provide email transfer and retrieval
services. User email can be stored on the server until retrieved by a POP3 client. To utilize the
mail server role, you must have:
• An active Internet connection
• A registered email domain name
• A registered mail exchanger (MX) record for your email domain with your Internet
Service provider (ISP)

Terminal Server
By installing the terminal server role, you enable users to connect to the server to run
applications as if the applications were installed on users’ workstations. I will discuss the
installation, configuration, and new features of the terminal server role throughout the book.
Unlike Win2K, which immediately grants access to all users when Terminal Services is installed,
WS2K3 restricts access by default to administrators only. You must add users or groups to the
Remote Desktop Users group to enable access.

Remote Access/VPN Server

Remote access and virtual private network (VPN) servers provide an entry point into your
network for remote users. By using the remote access/VPN server role, you can implement
routing protocols for both LAN and WAN environments. This role supports both dial-up
connections and VPN connections over the Internet.

Domain Controller
Domain controllers maintain the AD database. Domain controllers provide authentication
services for users and computers and control access to network resources. The domain controller
role replaces the DCPROMO tool that Win2K provides. This role lets you add a domain
controller to an existing domain, create a new domain in an existing forest, and create a new
forest.

4
 Chapter 1

DNS Server
The Domain Name System (DNS) is the TCP/IP name resolution service that is used on the
Internet. DNS lets computers resolve Fully Qualified Domain Names (FQDNs) to IP addresses.
The implementation of DNS that WS2K3 includes is a Dynamic DNS (DDNS) service, which
means that computers can self register into the DNS database. The WS2K3 implementation of
DNS also offers integration with the Windows Internet Naming Service (WINS) server role to
allow non-NetBIOS clients to resolve NetBIOS names via DNS.

DHCP Server
A Dynamic Host Configuration Protocol (DHCP) server will enable your TCP/IP-based clients
to be automatically assigned an IP address when needed. The DHCP server can also provide
additional network configuration information—DNS server IP addresses, WINS server
addresses, and so on—to the clients. Having a server with the DHCP role installed greatly
reduces the time required to set up and configure clients on your network.

Streaming Media Server

Streaming media servers provide Windows Media Services to network clients. Windows Media
Services manages and delivers Windows Media content—streaming audio and video—over an
intranet or the Internet.

WINS Server
WINS lets NetBIOS clients resolve computer names to IP addresses. Unlike DNS, which
requires that the request include the FQDNs of the target system, WINS is designed to function
within an intranet environment, so simple NetBIOS names can be resolved. The WINS database
is dynamic, letting clients self-register their names upon receiving an IP address from the DHCP
server.

Although it is possible to run a Windows network without using NetBIOS or WINS, many utilities still
depend on the WINS database. Many record types are available in WINS that are not present in
DNS. These types let servers offering specific services (including Terminal Services) be easily
identified through browsing. One such utility is the Terminal Server Administration tool. Without a
WINS server on the network, you will need to manually specify terminal servers to manage.

5
 Chapter 1

Terminal Services Technology

So what is a terminal server? Windows was designed to be a single-user operating system (OS),
meaning only one user could be interactively logged onto a system at a time. Terminal Services
breaks that model by implementing a Session Manager layer between the system and user layers.
The Session Manager responds to new session requests by creating a separate instance of the
Win32 subsystem, WIN32K.SYS, for each session. The Session Manager then executes the
client server runtime subsystem, CRSS.EXE, and the windows logon service,
WINLOGON.EXE, within the session. Figure 1.3 shows the processes that make up Terminal
Services divided up between user mode and kernel mode and indicates whether they are per
server or per session.

Figure 1.3: Services that create a multi-user environment.

This process allows multiple user sessions to run simultaneously on a Windows system. Session
Manager acts like a maitre d’ in a restaurant, directing new patrons (clients) to their tables
(sessions), then directing the serving staff (applications, services, and resources) to the new table.
Session Manager assigns each session a unique ID and address space so that resource and
network requests can be directed to the correct user.
Another very important component to Terminal Services is RDP. This presentation layer
protocol is what allows users to interact with sessions running on a remote server. Without RDP,
each user would need to have a console directly connected to the server.
RDP functions as a virtual display, keyboard, and mouse on the server. Instead of sending video
output to the VGA port, terminal servers redirect it to the video channel in the RDP stack. Doing
so transmits the display information across the network and draws it on the client’s workstation
display. RDP also takes keystrokes and mouse movements at the remote client and transmits
them back to the terminal server, where they are processed as if they came from a local keyboard
and mouse.

6
 Chapter 1

By using Terminal Services, you can install applications on a few servers in a datacenter rather
than on hundreds of workstations. You can also take advantage of inexpensive and highly robust
solid-state thin clients instead of managing the lifecycle of workstation hardware. If you have an
environment that requires personal computers for your end users, you can still leverage terminal
servers to centralize network traffic for specific high-bandwidth client/server applications.
Many companies also use terminal servers for remote access. Doing so enables the organizations
to lock down the majority of the network and allow remote connections to only a few servers.
These servers can be easily maintained with the latest security patches, hotfixes, and virus
protection.

New Answers for Old Challenges

If you manage terminal servers in your environment today, you already know many of the
challenges that they pose—configuring user accounts, managing roaming profiles, load-
balancing servers, configuring protocol settings, and managing printing. With WS2K3, many of
these tasks become much easier to deal with.

Remote Desktop
The first change you will notice in WS2K3 Terminal Services is the elimination of Remote
Administration Mode. Under Win2K, this mode of Terminal Services is used to enable two
remote sessions in addition to the console session for systems administration. This terminology
causes a great deal of confusion for systems administrators because enabling Terminal Services
does not necessarily make a server a “terminal server.” Also, Remote Administration Mode
causes a server to register as a terminal server in WINS and thereby shows up in the Terminal
Server Administration tool. This behavior makes finding your Win2K application terminal
servers more difficult.
Don’t be alarmed, you will still be able to remotely administer your WS2K3 servers. However,
instead of installing Terminal Services, you simply enable Remote Desktop. If you have been
using Windows XP, you are already familiar with Remote Desktop. Under WS2K3, Remote
Desktop allows the creation of two RDP-based virtual sessions as well as a remote connection to
the server’s console session—something that administrators have been asking for since the
release of Win2K. Also, unlike Remote Administration Mode in Win2K, WS2K3 Remote
Desktop does not cause the server to be listed in the Terminal Server Administration tool.

To force a server with Remote Desktop enabled to show up in the Terminal Server Administration
tool, in the registry, change the TSAdvertise value from 0 to 1 in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server subkey.

To enable Remote Desktop, go to the System Control Panel applet, select the Remote Tab, and
select the Allow users to remotely connect to your computer check box, as Figure 1.4 shows. By
default, only members of the local administrators group will be allowed to connect remotely, but
you can add users to the Remote Desktop Users group. Keep in mind, however, that enabling
Remote Desktop does not enable any application compatibility subsystems, so applications may
not function correctly for users other than the installer.

7
 Chapter 1

Figure 1.4: Enabling Remote Desktop.

Microsoft has added the ability to connect to and shadow the console session to WS2K3
Terminal Services. To connect to the console session, you can either use the Remote Desktop
administration tool or launch the Remote Desktop Connection client with the /console switch. To
shadow the console session, use the Terminal Server Administration tool just as you would to
shadow any other RDP session.

To quickly shadow the console session of a server you are already connected to via RDP, open a
command prompt and type
SHADOW 0
(that is a zero).

Compatibility Modes
Like Win2K, WS2K3 offers two compatibility modes for Terminal Services: Full Security and
Relaxed Security. Compatibility modes let you run legacy applications that cannot function
under WS2K3’s more restrictive file and registry permissions.

I’ll cover the differences between the modes in Chapter 5.

8
 Chapter 1

RDP 5.2 Protocol Enhancements

Some of the biggest changes in WS2K3 Terminal Services from previous versions come in the
enhancements made to RDP. The protocol now supports several new resource redirection
abilities. You might be familiar with some of them if you have been using Windows XP’s
Remote Desktop ability. These enhancements bring RDP up to par with Citrix’s ICA protocol in
many ways.
You are now able to redirect client drives, audio output, clipboard, ports, time zone, and
Windows keys (for example, ALT+TAB). RDP 5.2 even supports smart card authentication. All
of these features can be enabled or disabled at the server by the administrator. RDP 5.2 adds
support for greater color depth—up to 24-bit full color—and screen resolutions up to 1600 ×
1200. Table 1.1 shows a comparison between RDP 5.2 and ICA.
Feature RDP 5.2 ICA
Client drive mapping Automatically connects to all Automatically connects to client
client local and network drives local drives
Client clipboard mapping Automatic Automatic
Shadowing Supported Supported
Mapping of local client printers Automatic Automatic
Mapping of client network printers Automatic Automatic
Smart card sign on Supported Supported
Reconnection of dropped sessions Automatic Automatic
Sound Supported Supported
Encryption Up to 128 bit Up to 128 bit
Compression Automatic Automatic
Client time zone mapping Supported Supported
Windows keys Automatic Requires alternative key
combinations
Client serial and parallel port Automatic Automatic
mapping
Supported client OSs Win32, Win16, Windows CE, Win32, Win16, Windows CE,
CE.NET, PocketPC, Macintosh PocketPC, MS-DOS, UNIX,
Macintosh, Linux, Java
Transport protocol TCP/IP TCP/IP, IPX/SPX, NetBEUI
Seamless Windows Not available natively Automatic

Table 1.1: Comparison of RDP 5.2 and ICA.

9
 Chapter 1

Remote Desktop Connection Client

Remote Desktop Connection is the new client for RDP 5.2. Remote Desktop Connection
supports all of the new features of RDP 5.2. It eliminates the Connection Manager interface and
no longer stores connection definitions in the registry. Instead, Remote Desktop Connection
supports RDP Files—text files containing connection parameters to connect to a terminal server
or Windows XP Remote Desktop. With RDP Files, it is easy to distribute or centrally store
common connections for your users.
Through the Remote Desktop Connection interface, which Figure 1.5 shows, you can control
connection options—resource redirection, initial program, and window size. There is also a new
option called Experience through which you can enable or disable features of the new Aqua
interface in Windows XP and WS2K3—wallpaper, themes, and menu animation—to improve
performance over low-bandwidth connections.

Figure 1.5: The Remote Desktop Connection client.

10
 Chapter 1

Group Policy–Based Configuration

Under WS2K3, you can now centrally configure and manage virtually all Terminal Services
parameters via Group Policy. Figure 1.6 shows some of the settings available.

Figure 1.6: Group Policy settings for WS2K3 Terminal Services.

As you can see, Microsoft has provided the centralized control we’ve always wanted.

I’ll go over the available settings and recommended usage in Chapter 2.

ADSI Access to User Parameters

Under Win2K, the only Terminal Services parameter of a user object that was accessible from
the command line was the Terminal Services Profile Path attribute; accessing this attribute
required the TSPROF tool. WS2K3 exposes all Terminal Services attributes to ADSI. Using the
Windows Script Host (WSH) and your preferred scripting language, you can now easily
configure users’ Terminal Services settings. I’ll discuss the ADSI objects and provide some
sample scripts in Chapter 4, but for now, here is a list of the available attributes:
objUser.ConnectClientDrivesAtLogon
objUser.ConnectClientPrintersAtLogon
objUser.DefaultToMainPrinter
objUser.TerminalServicesInitialProgram
objUser.TerminalServicesWorkDirectory
objUser.TerminalServicesProfilePath
objUser.TerminalServicesHomeDirectory
objUser.TerminalServicesHomeDrive
objUser.AllowLogon

11
 Chapter 1

objUser.MaxDisconnectionTime
objUser.MaxConnectionTime
objUser.MaxIdleTime
objUser.BrokenConnectionAction
objUser.ReconnectionAction

Session Directory
When using WS2K3 Enterprise Edition for terminal servers in a load-balanced environment, you
can use the new Session Directory service to provide a single point of entry into the terminal
server farm. Session Directory not only acts as a load balancer—connecting users to the least
loaded server, but also maintains a database of active sessions in the farm. This feature enables a
disconnected user to resume an active session on the same server from which the user was
disconnected.
When a user connects to the farm through the Session Directory server, Session Directory checks
the list of active and disconnected sessions; if the username is found in the database, the
connection is directed to the server running the session. Session directory can be used with
Microsoft’s load-balancing service or any third-party load balancer.

I will cover Session Directory in depth in Chapter 3.

Terminal Services Licensing

For a terminal server to continue accepting connections after the 120-day trial period, you must
configure a Terminal Services Licensing server. WS2K3 adds new options and new layers of
complexity to the Terminal Services licensing landscape. To connect to a WS2K3 terminal
server, clients will need to be issued new WS2K3 license tokens. These new tokens can only be
issued by a WS2K3 Terminal Services License server—Win2K license servers cannot issue
these new tokens. Thus, even if your environment already contains a Win2K license server, you
will be forced to either upgrade that server to WS2K3 or activate a separate WS2K3 license
server.

Terminal Server Licensing Components

Terminal Services licensing consists of the Microsoft Clearinghouse, one or more WS2K3
Terminal Services Licensing servers, and one or more terminal servers. You access the Microsoft
Clearinghouse to activate license servers and obtain license key packs to be installed on the
Terminal Services Licensing server. The clearinghouse can be accessed directly over the
Internet, through a Web page, or by telephone.
A Terminal Services Licensing server can be any edition of WS2K3 with Terminal Services
Licensing installed. The Terminal Services Licensing server stores all Terminal Services CAL
tokens and tracks the tokens that have been issued to computers or users. All terminal servers
must be able to communicate with the Terminal Services Licensing server to issue permanent
tokens. If the licensing server has not been activated, it will issue only temporary licenses.

12
 Chapter 1

The terminal server is any WS2K3 edition with the terminal server role installed. When a client
connects to the terminal server, the server first determines whether the client needs a license
token. If so, the server contacts the licensing server and requests a token on the client’s behalf,
then delivers the token to the client. The first time a client connects to a terminal server in per-
device licensing mode, a temporary token is issued. Temporary licenses are stored on the
Terminal Services Licensing server for 90 days. Only at the second connection (within 90 days)
is the permanent CAL assigned to the device.
The term “permanent” is not really accurate here, as device tokens are set to expire after a
random number of days (between 52 to 89 days). This configuration is designed to recapture
CALs that have been issued to devices that are no longer in the environment or have had their
OSs re-installed. This behavior was first implemented in Win2K Service Pack 3 (SP3).

License Types
A WS2K3 Terminal Services Licensing server can manage seven types of license tokens. In
addition to supporting the CALs required for connecting to Win2K terminal servers, there are
three new types of CALs specific to WS2K3 Terminal Services (the following list shows the
three new types as well as the three types that have been supported since Win2K):

There are no built-in licenses for WS2K3 Terminal Services. You will need to purchase CALs for all
devices or users connecting to these servers regardless of the client OS.

• WS2K3 Terminal Server Device CALs—WS2K3 terminal servers that are in Per Device
licensing mode will request these licenses from the Terminal Services Licensing server.
• WS2K3 Terminal Server User CALs—WS2K3 terminal servers that are in Per User
licensing mode will request these licenses.
• WS2K3 Terminal Server External Connector licenses—These licenses allow unlimited
connections to a terminal server running WS2K3 by external users. These licenses are not
yet available.
• Win2K Terminal Services CALs—Terminal servers running Win2K will request these
licenses from the licensing server for clients running OSs other than Win2K Professional
or Windows XP. You only need these licenses if you have terminal servers running
Win2K.
• Win2K Terminal Services Internet Connector licenses—These licenses allow as many as
200 simultaneous anonymous connections to a terminal server running Win2K by non-
employees across the Internet.
• Win2K Built-In licenses—Clients that are running Win2K Pro or Windows XP are issued
a token from the built-in pool of license tokens when connecting to a terminal server
running Win2K.
Figure 1.7 shows the licenses available in the Terminal Server Licensing administration tool.
Notice that user CAL tokens are tracked separately from device CAL tokens. User CAL tokens
are new in WS2K3. Terminal servers can now be placed into either Per Device or Per User
licensing mode. A single Terminal Services Licensing server can serve tokens to terminal servers
in any combination of these modes if the proper licenses are installed.

13
 Chapter 1

Figure 1.7: License types available in the Terminal Server Licensing administration tool.

Installing Terminal Server Licensing

Unless you are working in a single server environment, Terminal Server Licensing should be
installed on a separate server from Terminal Services. If you are in a domain environment, you
will probably want to install the licensing service on a domain controller, as doing so makes the
discovery process easier for the terminal servers.
To install Terminal Server Licensing, go to the Add/Remove Programs Control Panel applet, and
select Add/Remove Windows Components. In the Windows Components Wizard window, select
the Terminal Server Licensing check box, as Figure 1.8 shows.

Figure 1.8: Installing Terminal Server Licensing.

14
 Chapter 1

If you are installing Terminal Server Licensing on a server in AD, you are presented with two
options for the mode of the server: Domain/Workgroup and Enterprise. The mode selected
determines how the licensing service advertises itself to the terminal servers. If you are in a
workgroup or non-AD domain, the Enterprise option is not available.
I will explain the discovery process in the next section, but for now, you should understand that
an Enterprise license server will be discoverable by terminal servers from any trusted domain but
only within the same AD site as the licensing server. Whereas, a Domain/Workgroup license
server will be discoverable only by terminal servers in the same workgroup or domain, but,
depending on the type of domain, may be discoverable across site boundaries.
After you install Terminal Server Licensing, the license server must be activated by contacting
the Microsoft Clearinghouse. Launch the Terminal Server Licensing administration tool from the
Start menu, right-click the server, and click Activate Server. The Terminal Server License Server
Activation Wizard will launch, offering you three options for contacting Microsoft. Figure 1.9
shows the options in the wizard:
• Automatic connection—This method is the easiest way to activate the licensing server.
This method requires that the server running Terminal Server Licensing has Internet
connectivity on port 443 (Secure Sockets Layer—SSL). Simply fill in the company and
contact information, and click Activate.
• Web Browser—If the server running Terminal Server Licensing does not have Internet
connectivity, you can still activate the server over the Web from another computer. To do
so, from a Web browser, go to https://activate.microsoft.com, and fill in the company and
contact information as well as the unique Terminal Server Licensing ID number that the
activate server wizard provides. The Web site will respond with the activation code that
you can then enter into the licensing service.
• Telephone—If you do not have Internet connectivity, you can contact the Microsoft
Clearinghouse by telephone. Select your country/region in the activate server wizard, and
the correct phone number will be displayed. Provide the customer service person your
company name, contact information, and server ID code, and they will provide you with
the activation code. Be sure to either activate the server while still on the phone with the
customer service representative or be very careful to record the activation code
accurately.

15
 Chapter 1

Figure 1.9: Activating a Terminal Services Licensing server.

After the license server is activated, it will immediately begin to issue temporary Win2K and
WS2K3 terminal server tokens, which gives the administrator a 90-day period in which to install
the appropriate permanent CALs on the license server so that it can issue permanent tokens.

If you are upgrading a Win2K server with Terminal Server Licensing installed to WS2K3, you might
need to re-activate the licensing service. To do so, select Re-Activate Server from Advanced in the
Actions menu in the Terminal Server Licensing administration tool.

To add a license pack to the license server, right-click the server in the Terminal Server
Licensing administration tool, and click Install Licenses. You will have the same connection
options as you had to activate the server. If you are installing a retail license pack, the type of
license will be automatically selected. If, however, you are installing licenses through a Select,
Open, or other Microsoft license agreement, you will have to select which type of licenses you
want to add. Figure 1.10 shows the Terminal Server CAL Installation Wizard.

16
 Chapter 1

Figure 1.10: Adding licenses to a Terminal Services Licensing server.

License Server Discovery

When Terminal Services is started, the server attempts to locate terminal server license servers
using a predefined discovery process. The method used is dependant on the server environment
and the mode in which the licensing server is configured to run. You can override the discovery
process by modifying the registry to point to a specific license server or servers. Under Win2K,
you can specify only a single license server in the registry, whereas WS2K3 lets you list multiple
preferred license servers. To override the discovery process, add subkeys to the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters\Li
censeServers subkey. Each subkey should be named with the hostname of the license server that
you want the terminal server to use. Figure 1.11 shows a registry with two license servers
defined.

17
 Chapter 1

Figure 1.11: Overriding license server discovery by specifying license servers in the registry.

If you don’t predefine license servers in the registry, the discovery process proceeds as follows:
workgroup and non-AD domain–based terminal servers send a mailslot broadcast to locate
license servers. Thus, only license servers in the same subnet will be discovered.
AD-based terminal servers first look for any license servers in Enterprise licensing mode. They
do so by performing a Lightweight Directory Access Protocol (LDAP) query for the CN TS-
Enterprise-License-Server, specifying their own site as the scope. The terminal server then
contacts each domain controller within its site looking for a Domain license server. Finally, the
terminal server will contact all remaining domain controllers within its domain.
Once the discovery process is complete, the terminal server caches all license servers that were
discovered in the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Parameters\EnterpriseServe
rMulti and
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Parameters\DomainLicense
ServerMulti.
It is important to note that if both Enterprise and Domain license servers are found, the terminal
server will always prefer to use the Domain license server—even if a site boundary must be
crossed to do so. Also, if no license servers are found, the terminal server will repeat the
discovery process once every hour until a license server is found. Once one or more license
servers are found, discovery is not repeated until such a time when none of the servers cached in
the registry are available.

18
 Chapter 1

License Assignment
Every time a client connects to a terminal server, the license server is contacted to either validate
an existing license or issue a new license. The type of licenses that a terminal server will issue is
determined by its licensing mode—Per Device or Per User. You can set the mode through either
the Terminal Services Configuration administration tool or by Group Policy. The default is Per
Device mode, unless you are upgrading Win2K terminal server that is in Internet Connector
mode, in which case it will default to Per User mode.

In order to support both Per User and Per Device tokens, the terminal server must be in Per User
mode.

The following steps walk you through the process taken by a terminal server at each client
connection:
1. Regardless of the licensing mode, the terminal server will first query the client device to
determine whether a device token has been written to the registry. If a token is present,
the terminal server will contact the license server indicated in the token to validate the
license. If the license is a temporary license, the license server will assign a permanent
token at this time, which will be recorded in the client registry.
2. If the client device does not have a token, the next step is dependent on the licensing
mode of the terminal server:
a. Per-User licensing mode—The terminal server requests credentials from the user
and performs authentication. The terminal server will then query the license
server to either validate that the user has a token assigned or request a license for
the user. The token is stored on the license server.
b. Per-Device licensing mode—The terminal server will request a temporary token
from the license server and write it to the client registry. After the user has been
authenticated, the terminal server instructs the licensing server to mark the
temporary token as validated. If the user does not authenticate, the token is
immediately returned to the pool of available licenses.
3. In either case, if the license server does not have any tokens available, another license
server is contacted. If the first license server is aware of another license server that has
licenses available, it will request the token on behalf of the terminal server. If the license
server does not know of other license servers in the environment, the terminal server will
query the next license server cached in the registry.
In most cases, license servers will inform each other when licenses are added to or removed from
their pools. This communication allows the license servers to proxy requests for licenses to other
licensing servers. This process is called License Token Announcement and occurs in the
following scenarios:
• Between domain license servers within the same domain
• Between enterprise license servers within the same site and domain
• From enterprise license servers to domain license servers
• From Win2K license servers to WS2K3 license servers

19
 Chapter 1

License Server Administration

After your license servers are activated and have licenses installed, there is very little
administration to be done. However, there are a few utilities that you should familiarize yourself
with in order to troubleshoot any licensing issues that may arise.
The Terminal Sever Licensing tool is the primary administration tool. Figure 1.12 shows the
interface. This tool is used to activate a license server, install licenses, and view available and
assigned license tokens. Through this interface you can view which users and devices have been
assigned CAL tokens, the date that the token was assigned, and when it will expire.

Figure 1.12: The Terminal Server Licensing tool interface.

The WS2K3 resource kit contains a command-line interface to the Terminal Server Licensing
tool—LSREPORT.EXE. With this tool, you can output a list of tokens assigned by a license
server. This tool accepts parameters to limit the date range of licenses to include, include only
temporary licenses, include the hardware ID of device tokens, and specify which license server
or servers to query.
Another resource kit utility is the Client License Test Tool—TSCTST.EXE. This tool is used to
query details about device tokens installed on a given client. The default output includes the
name of the license server that issued the token, the scope, the name of the computer, the user
that was authenticating when the token was issued, the license ID, and the date range for which
the license is valid. When executed with the /A switch, the tool will also include the server
certificate version, the licensed product version, the hardware ID, the client platform ID, and the
company name in the output.
The License Server Viewer Tool—LSVIEW.EXE, which Figure 1.13 shows—is also included in
the resource kit. This GUI-based tool performs a license server discovery process and displays
all Terminal Services license servers in the environment. It also identifies the type of license
server—Domain or Enterprise—and can create a log with diagnostic information about the
discovery process.

20
 Chapter 1

Figure 1.13: The License Server Viewer interface.

License Server Group Policy Settings

WS2K3 includes several Group Policy settings to control terminal server licensing. With these
settings, it is easy to centrally configure license servers and maintain consistency in the
environment (Figure 1.14 shows the available settings in the Group Policy Object Editor):

Figure 1.14: The License Server Group Policy settings.

21
 Chapter 1

• License Server Security Group—By default, a license server will issue tokens to clients
connecting to any terminal server. If you enable this setting, the license server will only
respond to requests from terminal servers in the Terminal Services Computers local
group. If the licensing server is a domain controller, this is a domain local group.
Enabling this setting prevents rogue terminal servers from requesting licenses and lets
you enforce separate license pools for groups of terminal servers in your environment. If
you have more than one license server providing licenses for a single group of terminal
servers, be sure to add the license servers to the group, as they can request licenses on
behalf of the terminal servers.
• Prevent License Upgrade—As you know, a WS2K3 license server can distribute both
Win2K terminal server device CALs and WS2K3 terminal server device CALs. If a
Win2K terminal server requests a token, and the license server does not have any Win2K
terminal server CALs available, it will automatically issue a WS2K3 Per-Device token (if
there are any available). This behavior can be prevented by enabling this policy setting.
With it enabled, the license server will only issue temporary tokens to clients connecting
to Win2K terminal servers. If the client’s temporary token has expired, the connection
will be refused.

The Terminal Services Computers group is empty be default; be sure to add servers to the group
before enabling the policy setting to prevent refused connections.

Summary
In this chapter, I introduced you to the new role-based model in WS2K3. I also briefly covered
the new features of Terminal Services. I will continue to address these enhancements throughout
the book. Finally, I went into depth about Terminal Services licensing, as a thorough
understanding of licensing is required to maintain a terminal server infrastructure for more than
120 days.
In Chapter 2, I will cover the installation and configuration of Terminal Services. I will take you
through all the new Group Policy settings for Terminal Services, and show you a few tricks to
use to make administrating groups of servers easier.

22
 Chapter 2

Chapter 2: Installing and Configuring the Terminal Server

Role
This chapter will take you through the steps of adding the terminal server role to WS2K3. I’ll
introduce you to the settings used to configure a terminal server via the administrative tools,
Group Policy, and registry editor, and even give you a few system tweaks to help improve your
server’s performance. Finally, I will give you an in-depth look at the Remote Desktop
Connection client, and the new version of the Terminal Server Advanced Client (TSAC)—
Remote Desktop Web Connection. I’ll begin by exploring the most common reasons for
deploying Terminal Services.

Terminal Services Deployment Scenarios

What are the biggest challenges you face managing a Windows desktop environment? Answer
truthfully, and I’m sure these are among your top five:
• Software deployment
• Virus protection
• Software updates
By using Terminal Services, you can greatly reduce the difficulty of these tasks. WS2K3’s
terminal server role can enable you to centralize software, decrease the number of Windows
systems in the environment, and prevent exposure to viruses by centrally managing virus scanner
updates and creating a single point of entry for remote access users.
There are three basic models for utilizing Terminal Services:
• Desktop replacement—Remove the Windows PC from the user’s desk, and replace the
PC with a thin-client device.
• Remote access—Provide users in a remote location access to either a complete desktop
environment or individual applications over either a WAN link or Remote Access Service
(RAS) connection.
• Application service provider (ASP)—Provide access to individual applications to users at
their regular workstation without installing the applications locally on users’ PCs.

23
 Chapter 2

Desktop Replacement
At its most pervasive implementation, Terminal Services can allow an IT department to
completely eliminate PCs from users’ desks. This model provides many benefits, including
elimination of end-node support, rapid deployment of new or upgraded software, reduction in
power consumption, and added security. Depending on your corporate IT architecture, desktop
replacement can also reduce bandwidth requirements and eliminate the need for servers in
remote offices:
• Elimination of end-node support—Without PCs on users’ desks, there is no longer any
need to visit the workstation to configure the OS, install or repair software, assist a user
in configuring applications, or replace a defective hard drive. A thin-client’s OS is burned
into ROM, and applications are installed on the terminal servers. Help desk personnel can
provide user assistance via remote control of the terminal server session, and users can
replace a damaged device by simply plugging in a new one.

Most thin-client devices support auto-configuration via Dynamic Host Configuration Protocol (DHCP)
and FTP. You add a URL to a DHCP extension, and when the client boots, the client downloads its
configuration from the FTP URL. This setup enables even the least tech-savvy users to set up or
replace thin clients.

• Rapid deployment of new or upgraded software—If you work in a large IT environment,

you know how difficult and time consuming deploying software to your users can be. By
using Terminal Services and thin clients, you simply install the new software on your
servers, and overnight thousands of users will have access to it. There are even third-
party utilities that will assist you in deploying software to all of your terminal servers at
once.
• Reduction in power consumption—Thin-client devices have no moving parts and are
completely solid-state, so they typically consume about 10 percent of the power that a
normal Wintel PC consumes. With rising electricity costs, this reduced consumption can
provide a major cost-savings to your company.
• Added security—If a standard PC is stolen, you risk losing important and sensitive data
stored on its local hard disk, and you must pay to replace the computer. With the desktop
replacement model, there is no data stored on the end-node device, and the cost of
replacement is about half that of a normal PC.

There are many players in the thin-client device market (for example, Wyse Technologies’ Winterm
and Neoware EON). These devices can use any embedded OS at their core (Windows CE,
embedded Linux, and so on).

There are, however, some potential drawbacks to the desktop replacement model, including
limited adaptability to one-off applications, reduction in user settings personalization, and
increased initial deployment costs:

24
 Chapter 2

• Limited adaptability to one-off applications—If you have a very small group of users
who need an application, with the desktop replacement model, you’ll no longer have the
freedom to install the application on only those users’ desktops. You’ll be forced to
integrate the application into your Terminal Services infrastructure. Because of this
limitation, the desktop replacement model is best suited to homogeneous computing
environments.
• Reduction in user settings personalization—If your users are accustomed to personalizing
their workstations with wallpaper and screen savers or have the ability to install their own
software, you’ll have a small battle on your hands when they’re restricted from
performing some of these customizations.
• Increased initial deployment costs—If you already have a large user population and each
user has a PC, the initial setup costs of purchasing the thin-client devices and the robust
servers needed for terminal servers can seem a little overwhelming. However, in the long
term, the reduction in TCO will more than make up for the initial investment. Opening a
new office or call center is a perfect opportunity to implement the desktop replacement
model.

Remote Access
If these drawbacks or your corporate culture eliminate desktop replacement as an option, the
remote-access model may be a great alternative for you. Most big companies have a large
population of remote or nomadic users—telecommuters, executives traveling to satellite offices,
and so on. Although laptops provide the ability to work remotely, they don’t address the needs of
limited-bandwidth connections or remote support. In addition, laptops can be nearly double the
cost of a desktop, so your finance department may balk at the thought of providing a laptop for
users who only occasionally need remote access to applications.
The remote-access model can provide these users with the ability to access individual
applications or even a complete corporate desktop from the Internet (by using the Remote
Desktop Web Connection, a Web-based version of the Remote Desktop Connection client) or
from their home computers. In addition, the reduced bandwidth requirements of RDP provide
improved performance when compared with running laptop-based applications over a slow link.

Using a terminal server as a portal to the corporate LAN can shield your network from any viruses on
the remote computer.

As with any remote-access strategy, you must make security the top priority when considering
the remote-access model. Be sure to take the time to educate your network design engineers in
the specific needs of the terminal server protocols. In addition, implement a strategy to prevent
the abuse of any changes you implement to accommodate the terminal server network traffic.

25
 Chapter 2

ASP
When looking at a large-scale deployment of a vertical application, there are many factors to
consider:
• Deployment method (Sneakernet, Systems Management Server―SMS, IntelliMirror)
• Workstation system requirements (RAM, disk space, processing power)
• Support and back-out plan in case an installation goes awry
• Bandwidth requirements for client/server or database applications
If the application you are deploying doesn’t have complex OLE integration with other
applications on the users’ desktops, the ASP model might be right for you. Terminal servers,
especially when implemented with TSAC or a third-party application publishing product, can
give you the ability to provide users the applications they need quickly and easily without
touching their workstations. In this model, the application is installed on terminal servers, and
users launch it via a client application on their desktops or by using a Web browser.

I’ll go into the details of the ASP model in Chapter 5.

Installing the Terminal Server Role

When an administrator logs on to WS2K3, the Manage Your Server Wizard, which Figure 2.1
shows, provides easy access to the tools needed to install, configure, and manage server roles.
Here is where we will begin the process of installing the terminal server role.

Figure 2.1: The Manage Your Server wizard.

26
 Chapter 2

To start, click the Add or remove a role link to invoke the Configure Your Server wizard, which
Figure 2.2 shows. This wizard outlines the preliminary steps to adding a role. Confirm that you
are prepared, and click Next.

Figure 2.2: Preliminary steps to installing a role.

The wizard then scans your network connections to determine which roles are compatible, then
lists all available roles for your server, as Figure 2.3 shows.

Figure 2.3: Detecting your network settings to determine compatible roles.

27
 Chapter 2

In the window that results from the scan (see Figure 2.4), you will select the terminal server role,
then click Next.

Figure 2.4: The Configure Your Server wizard.

After warning you that adding this role will automatically reboot your server, the wizard will call
the Add/Remove Windows Components Control Panel applet and add the required services.
When complete, the system will reboot.

There is no option to postpone the reboot when adding a role via the Manage Your Server wizard.

When you log on to the system after the reboot, two windows will be automatically displayed.
One window confirms that the terminal server role has been successfully added, as Figure 2.5
illustrates.

28
 Chapter 2

Figure 2.5: A successful installation of the terminal server role.

The second window provides a helpful checklist of the common next steps needed to complete
the configuration of your terminal server (see Figure 2.6).

Figure 2.6: The common next steps required for configuring a terminal server.

29
 Chapter 2

Configuring the Terminal Server Role

As you can see in Figure 2.6, there are several steps you must take after installing Terminal
Services. We explore terminal server licensing in Chapter 1; in this section, I’ll discuss how to
configure a terminal server.

The reference materials available in the Plan your Terminal Server Deployment section of the
checklist are very helpful, so read through them.

There are two main tools used to configure a terminal server: the Terminal Services
Configuration tool and the Group Policy editor.

Terminal Services Configuration Administrative Tool

The main tool used to configure a terminal server is the Terminal Services Configuration
administrative tool. With this tool, you can set the permission mode for the server, configure
performance options, and configure RDP. You can launch Terminal Services Configuration in
one of three ways:
• From the Start menu, under Administrative Tools
• Directly from the Configure Terminal Server wizard checklist
• From the Manage Your Server wizard
Under the Server Settings node, which Figure 2.7 shows, you will find six options.

Figure 2.7: The server settings node of the Terminal Services Configuration tool.

30
 Chapter 2

Three of these choices—Delete temporary folders on exit, Use temporary folders per session,
and Active Desktop—you will most likely leave in the default settings. The following list
provides an explanation of these settings:
• Delete temporary folders on exit—Each user on a terminal server is given a temp
directory. This folder is found in C:\Documents and Settings\<username>\local
settings\temp. If this setting is enabled, the temp folder is purged when the user logs off
the server.
If you use roaming profiles for your users, and you enable the Delete cached copies of
roaming profiles Group Policy setting (a common practice on terminal servers), the
Delete temporary folders on exit setting becomes irrelevant as the entire profile directory
is deleted at logoff. However, it is a good idea to leave this setting enabled unless you
have an application that requires that temp files are persistent across sessions, in which
case, you will also need to disable the Group Policy setting as well.
• Use temporary folders per session—With this setting enabled, a new directory is created
under the users temp folder for each session the user has on the server. These folders are
named with a single digit (\temp\0, \temp\1, and so on). It is a good idea to leave this
setting enabled to prevent multiple sessions from interacting.
• Active Desktop—Starting with Windows 98, we have had the ability to embed active
content (Web pages, animations, news tickers, and so on) on the Windows desktop. To
reduce the number of screen redraws being sent to the client from the terminal server, this
setting is disabled by default.
The remaining three settings—Licensing, Permission Compatibility, and Restrict each user to
one setting—require a little more consideration and understanding. These settings are dependent
on your environment and the applications you intend to install on the terminal server. Let’s begin
by looking at permission compatibility.

Permission Compatibility
In Win2K, you were prompted to select a compatibility mode when installing Terminal Services.
The options were Permissions compatible with Windows 2000 Users and Permissions
compatible with Terminal Server 4.0 users. In line with Microsoft’s new focus on security,
WS2K3 defaults to Full Security mode. This mode is similar to the Win2K Users mode. Under
WS2K3 Full Security mode, non-administrators cannot modify the HKEY_LOCAL_MACHINE
registry key nor write files to anywhere on the server’s hard drive other than their profile
directory.
If you encounter applications that will not run under Full Security mode, you may need to
change to Relaxed Security mode. Use this option as a last resort, as it opens your server up to
inadvertent changes by non-administrators.

In Chapter 5, I will go over some alternatives to Relaxed Security mode that you can use to enable
some older applications to run on Terminal Services.

31
 Chapter 2

Licensing
The next setting to address is the licensing mode. This setting controls the type of licenses that
the terminal server will request from the license server on behalf of the clients. In most cases, the
default setting is Per Device, which means that you will need to install WS2K3 Terminal Server
Per Device tokens on your license server. However, if you are upgrading a Win2K terminal
server that has Internet Connector Licensing enabled, you’ll configure this setting to Per User
licensing.
The mode you select is dependent on your environment. If your environment is one in which
each user has multiple devices from which they will connect, Per User licensing may be easier to
manage and may even save you some money; whereas, if your users share computers, Per
Device licensing may be a better option. Perhaps you manage a call center in which one
computer is shared by three users, one in each shift. Per Device licensing would mean you would
only need one token to cover three users. If you set the server to Per User licensing, it will also
validate and accept connections from devices that have already been issued a Per Device token.

Restrict Each User to One Setting

The last setting to be considered is Restrict each user to one session. Enabling this setting will
prevent users from establishing multiple sessions on the server, which will help conserve
resources on the server by only allowing each user to take up the overhead of a single session
and run all required applications within that session. Keep in mind that if you are going to be
offering direct access to individual applications outside of a desktop environment, your users
might need the ability to run more than one application at the same time.

Citrix MetaFrame supports session sharing. This functionality lets a user launch multiple published
applications on the same server without establishing a separate session for each one.

Figure 2.8 shows the connections node of the Terminal Services Configuration administrative
tool. Through this node, you configure timeouts, security, and client resource redirection.

Figure 2.8: The connections node of the Terminal Services Configuration tool.

32
 Chapter 2

By default, you will see only one RDP-Tcp connection. If you are using a multi-homed server,
you can modify the default connection definition to apply only to one network interface, then
create a separate connection definition for your other interfaces. Also, if you have installed Citrix
MetaFrame, you will see one or more ICA connections here; it is advisable to use the Citrix
Connection Configuration tool to modify settings for the ICA protocol.
By right-clicking the connection, you can disable it entirely, rename it, or access its properties. If
you are familiar with the Win2K Terminal Services Configuration tool, the WS2K3 tool’s
interface looks quite familiar, with the addition of the new features of RDP 5.2 and the new
“secure by default” model.
The General tab of the RDP-Tcp properties (see Figure 2.9) lets you add a comment to the
connection and to set the encryption level. WS2K3 offers new encryption options:
• Low—All data sent from the client to the server is protected by 56-bit encryption.
• Client Compatible (the default setting)—All data sent between the client and the server is
protected by encryption based on the maximum key strength supported by the client.
• High—All data sent between the client and the server is protected by encryption based on
the server’s maximum key strength. Clients that do not support this level of encryption
cannot connect.
• FIPS Compliant—All data sent between the client and the server is protected by using
Federal Information Processing Standard (FIPS) 140-1 validated encryption methods.

Figure 2.9: The General and Logon Settings tabs of the RDP-Tcp connection properties.

On the Logon Settings tab, which Figure 2.9 also shows, you can control whether to allow users
to log on as themselves or specify a single account to automatically log on as users when they
connect to the server over RDP. On this tab, you can also select the Always prompt for password
option, which prompts the user for a password even if one is cached in the Remote Desktop
client.

33
 Chapter 2

Be careful about setting credentials for automatic logon, as doing so will prevent you from logging on
with an administrative account.

Figure 2.10 shows the Sessions and Environment tabs of the RDP connection. In these windows,
you set timeouts and reconnection settings as well as an initial program to launch. By default, the
settings on both of these tabs are inherited from the parameters set on the user account
connecting to the server. If you want to override the user account settings, do so here.
The Sessions tab contains timeouts for disconnected, idle, and active sessions. A disconnected
session is one in which the user actively disconnects from the server by either closing the
connection window without logging off or selecting Disconnect from the Start menu. An idle
session is one in which the user has left the connection window open, but has not executed any
mouse clicks or keystrokes in a given period of time. When a session loses its network
connection or reaches the idle timeout, you can specify whether to immediately end the session
or to treat the session as disconnected.
The Environment tab lets you specify a specific program to launch when a client connects to the
server. You must specify both the path and executable name. If you configure this setting, when
any user, including an administrator, connects to the server, the specified program will run
instead of a Windows Explorer desktop. Many administrators have made the mistake of thinking
that this setting is like the Startup folder in the Start menu, automatically launching a program
when the user logs onto the desktop. Such is not the case—configuring this setting replaces the
Explorer shell with the program specified.

Figure 2.10: The Sessions and Environment tabs of the RDP connection properties.

The next tabs we’ll explore are Remote Control and Client Settings (see Figure 2.11). These
control shadowing and client resource redirection, respectively. Once again, these settings inherit
their behavior from the user account or Remote Desktop Connection software by default.

34
 Chapter 2

When an administrator wants to remotely connect to an existing user’s session to provide

support, this action is called shadowing or remote control. On the Remote Control tab, you can
keep the default setting of inheriting shadowing settings from the user’s account attributes, or
you can specify your own for this server. If you specify settings here, your options are to enable
or disable the requirement for the user to give permission before being shadowed (via a popup
window) and to control the level of interaction that the administrator can have with the user’s
session—either view only or interact. If you select interact with the user’s session, the
administrator will be able to control the user’s mouse and enter keystrokes on behalf of the user.
You also have the option to disable remote control altogether.

Before disabling the Require the user’s permission setting, be sure to confirm that you are not under
a legal obligation to inform users when they are being shadowed. Many states and industries require
this communication with users.

The Client Settings tab lets you override the client resource redirection settings specified in the
Remote Desktop Connection client software. On this tab, you can enable or disable the
redirection of the following client resources:
• Drives
• Printers
• LPT ports
• COM ports
• Clipboard
• Audio
You can also specify whether to default to the main client printer and limit the maximum color
depth that a user can request when connecting to the server. Higher color depths can degrade
performance over slow connections.

35
 Chapter 2

Figure 2.11: The Remote Control and Client Settings tabs of the RDP connection properties.

The Network Adapter and Permissions tabs are dedicated to more server-centric settings (see
Figure 2.12). The Network Adapter tab lets you specify whether this set of connection settings
applies to all network adapters or, in the case of a multi-homed server, a specific adapter. The
Permissions tab is where you control who has the ability to connect to the server using RDP, and
what level of rights they have when it comes to accessing virtual channels interacting with other
sessions on the server. Figure 2.12 shows both of these tabs.
In addition to limiting the RDP connection to one network interface, the Network Adapter tab
lets you set a limit on the total number of connections allowed on the specified interface or on
the entire server if All network adapters configured with this protocol is selected. If you have
more than one network adapter in your server, and you select a specific adapter on this tab, you
will be able to create a new connection in the main Terminal Services Configuration window and
apply separate settings to it.
The Permissions tab is one in which major change has occurred since Win2K. Under Win2K, the
default permissions allowed all users from any trusted domain to immediately connect to the
server once Terminal Services was enabled. WS2K3 is secure by default and only allows
administrators and members of the Remote Desktop Users group to connect. Keep in mind that
the Remote Desktop Users group is empty by default, so in order for users to connect to your
terminal server, you will need to add them to this group.

If you are in an AD domain, you can use the Managed Group setting in Group Policy to control the
members of the Remote Desktop Users group.

36
 Chapter 2

Figure 2.12: The Network Adapter and Permissions tabs of the RDP connection properties.

Group Policy–Based Configuration

WS2K3 has exposed a large number of settings to the Group Policy editor that were not available
under Win2K. If your terminal servers are in an AD environment, you will definitely want to
take advantage of Group Policies; but even in a workgroup or NT 4.0 domain environment, the
terminal server settings are still available to you via the local machine policy. In this section, I’ll
go over some of the settings available in the Group Policy editor.

In Chapter 4, I’ll cover some advanced techniques available in an AD environment.

To access the local Group Policy editor, launch GPEDIT.MSC from a run command or
command line. Navigate to the Terminal Services settings node in Computer Configuration,
Administrative Templates, Windows Components, Terminal Services. As you can see in Figure
2.13, there are many settings available.

37
 Chapter 2

Figure 2.13: Terminal Services settings in the Group Policy Object Editor.

Settings are divided into categories: Encryption, Licensing, Sessions, and so on. You’ll notice
that several settings are identical to those found in the Terminal Services Configuration tool. The
reason is so you can centrally manage settings on your servers without having to configure each
server manually. Some settings to take a close look at are:
• Set path for TS Roaming Profiles—This setting lets you specify a server and share in
which to store terminal server user profiles. You can also specify a TS profile path on
each user’s account. This setting not only lets you override the setting in the user account
on a per server basis, but also enables you to specify a different terminal server profile
server for groups of terminal servers. This ability is helpful if you have geographically
dispersed server farms and users that roam between them.
• TS User Home Directory—This setting is similar to the previous setting except that this
one specifies a server and share to create home directories for users logging on to the
terminal server.

When configuring either of the previous settings, do not attempt to specify a per-user subdirectory.
The server will automatically append %username% to the path.

• Do not allow local administrators to customize permissions—This setting disables the

Permissions tab in the Terminal Services Configuration tool. Because WS2K3’s RDP is
restricted by default and the preferred method of granting users access to the terminal
server is by adding them to the Remote Desktop Users group (as opposed to adding new
groups to the RDP permissions), you can now disable the tab entirely.

38
 Chapter 2

The licensing node under Terminal Services is used to configure a terminal server license server
by enforcing a license server security group or disabling license upgrades. A license server
security group restricts the license server to only issuing tokens to servers that are members of
the Terminal Services Computers security group. Disabling license upgrades prevents the license
server from issuing WS2K3 terminal server tokens to clients connecting to a Win2K terminal
server. By default, if the license server has no Win2K terminal server tokens available, it will
issue WS2K3 tokens instead.
The Session Directory node is used to configure terminal servers that are members of a Session
Directory cluster. Through this node, you can specify the name of the cluster and the Session
Directory server and control the behavior when clients attempt to reconnect to an existing session
on the cluster.

I will cover Session Directory in depth in Chapter 3.

In addition to these settings, there are a few more settings of interest to terminal server
administrators. Under Computer Configuration, Administrative Templates, System, User
Profiles, there is an option to Allow only local user profiles. This setting prevents a server from
downloading roaming user profiles, even if one is configured on the user’s account. This setting
comes in handy if you have a terminal server at a separate site than your profile server and you
do not want to establish a separate profile server for the site. By enabling this policy, when a user
logs onto the server, a local profile is created and stored on the server.
The User Profiles node also holds the Delete cached copies of roaming profiles setting. This
setting instructs the server to purge the local copy of a profile when a user logs off (if the user
has a roaming profile). This setting lets you save disk space on your terminal server and prevents
old versions of profiles from merging with the network copy if a user hasn’t logged onto a
particular terminal server in a while.
If you look under User Configuration, Administrative Templates, Windows Components,
Terminal Services, you will see that the settings for remote control, environment, and session
timeouts are available here in addition to the Computer Configuration node. This dual
accessibility allows you to configure these settings on a per-user basis if you choose.

In most cases, if you configure the same setting in both Computer Configuration and User
Configuration, the machine setting wins.

Additional Configuration Settings

In addition to the settings available in the Terminal Services Configuration tool and the Group
Policy Object Editor, there are several settings that most Terminal Services administrators
control via manual registry edits. These settings let you improve performance on your servers by
increasing the number of idle RDP sessions and disabling display features to minimize screen
redraws:

39
 Chapter 2

• Idle RDP connections—By default, the server creates two idle RDP sessions to respond
when a client opens a connection. These sessions are immediately replaced with a new
idle session when a user connects, but to prevent the rare case when more than two
connections are established at the exact same moment, you can increase the number of
idle sessions. I recommend increasing it to five by setting the IdleWinStationPoolCount
value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server subkey to 5.
• User overrides for desktop settings—These settings override the user’s preferences when
logging on over RDP to optimize performance and reduce screen refreshes. To disable
animation when resizing windows, set the MinAnimate value in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\WinStations\RDP-Tcp\UserOverride\Control Panel\Desktop\WindowMetrics
subkey to 0. In addition, you can set the following values (defined in Table 2.1) of the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\WinStations\RDP-Tcp\UserOverride\Control Panel\Desktop subkey.
Value Setting Description
AutoEndTasks 1 Automatically terminates
programs that aren’t responding
CursorBlinkRate -1 Prevents the cursor from
blinking, which cuts down on
screen redraws
DragFullWindows 0 Doesn’t show contents while
dragging a window
MenuShowDelay 10 Sets the delay for showing
submenus
WaitToKillAppTimeout 20000 The number of milliseconds to
wait before terminating an
application that isn’t responding
SmoothScroll Dword-type value of 00000000 Disables smooth scrolling
Wallpaper (none) Disables wallpaper

Table 2.1: Registry values to set user override settings.

In addition to these registry changes, you should change the following settings to tune the overall
server performance:
• Tune the event logs—In Event Viewer, adjust the properties of each log so that its
maximum size is 1MB (or larger if you want an extended history), and set it to overwrite
as needed. These settings can also be controlled in a domain Group Policy under
Computer Configuration, Security Settings.
• Configure the capture of debugging information—In the Advanced Startup and Recovery
Options of the System Control Panel applet, adjust the Write Debugging Information
settings to save the debug dump to an appropriate location (or disable it entirely), and
confirm that the server is set to automatically reboot.

40
 Chapter 2

• Examine the Run registry key—Under

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run,
there can be values pointing to executables to launch at the start of each session. Some
applications (including certain virus scanners, network teaming, and load balancing
utilities) add entries here to create system tray icons. Usually these icons only provide
easy access to control panel or configuration utilities and do not really need to be run at
all times. By removing these entries, you can reduce the overhead of having these applets
run in every terminal server session. Be sure to check with the application vendor before
removing.

Installing and Configuring the Remote Desktop Connection Client

After you have installed and configured a terminal server, you will want to provide access to the
server via a client interface. There are two versions of the Remote Desktop Connection client:
the local version, available for Windows 32-bit OSs, Macintosh, and PocketPC; and the Remote
Desktop Web Connection, an ActiveX control used to connect to a terminal server through an
Internet Explorer (IE) window.
Which client you use depends on your needs. If you want to maintain the configuration of
terminal server connections on the clients (by distributing RDP files or letting users manually
enter server names), the Remote Desktop Connection client is perfect. If, however, you want to
centrally control the connection (server names, initial programs, experience options), the Remote
Desktop Web Connection might be a better option.

Remote Desktop Connection Client

The Remote Desktop Connection client comes pre-installed on all WindowsXP computers, as
this is the same client used for Windows XP’s Remote Desktop feature. If you want to install or
deploy it on other OSs, you can download it from
http://www.microsoft.com/windowsserver2003/technologies/terminalservices/default.mspx. The
client can be installed on the following OSs: Windows 95, Windows 98, Windows 98 Second
Edition, Windows Me, Windows NT 4.0, Win2K, and Macintosh. You can also download the
Terminal Services Client for PocketPC from
http://www.microsoft.com/mobile/pocketpc/downloads/default.asp. Figure 2.14 shows the
Remote Desktop Connection client’s interface.

41
 Chapter 2

Figure 2.14: The Remote Desktop Connection client.

In the client’s interface you can set the following options:

• Name or IP address of the terminal server to connect to
• Username and password to use when connecting
• Screen size
• Color depth
• Sound, local drive, printer, and COM port mapping
• Behavior of Windows key combinations (interpreted by the client or by the server)
• An initial program to run in lieu of a desktop
• Experience options (enable or disable certain visual effects to improve performance over
slow connections)
Once you set your options the way you like, you can save the configuration to an RDP file. This
file is a text-based file that can be executed for easy connection to a specific server or
application. Administrators can pre-create RDP files for users and distribute the files via email.

42
 Chapter 2

If you copy an RDP file with a saved password to another computer, the password will not be entered
upon connection. This behavior is important to know if you intend to distribute RDP files with
credentials included.
If an administrator has configured any of the options in the Terminal Services Configuration tool and
the Group Policy Object Editor that correlate to settings available in the client, the server settings
override those requested by the client. Settings in Group Policy take precedence over both the
Terminal Services Configuration tool and the client options.

You can also control the Remote Desktop Connection client via the command line. Listing 2.1
shows the syntax.
MSTSC [<Connection File>][/v:<server[:port]>] [/console]
[[/f[ullscreen]|[/w:<width> /h:<height>]]|[/Edit”connection
file”][/Migrate]

<Connection File> - specified the RDP file for the connection

/v:<server[:port]> - specifies the server name or IP address to connect
to and the port on which to connect
/console – connect to the console session of a Windows Server 2003
/f[ullscreen] – starts the client in full screen mode
/w:<width> /h:<height> - specifies a height and width for the
connection window
/edit – opens an RDP file for editing
/Migrate – migrates legacy Client Connection Manager connections out of
the registry and into RDP files.

Listing 2.1: Syntax for configuring the Remote Desktop Connection client via the command line.

The command line is the only way to connect to the console session of WS2K3 using the Remote
Desktop Connection client. There is a GUI option for this in the Remote Desktops Administrative Tool
on WS2K3 or in the WS2K3 Administrative Tools package available for installation on Windows XP.

Remote Desktop Web Connection

The Remote Desktop Web Connection installs on an Internet Information Server (IIS—or a
WS2K3 system that has the application server role enabled). The Remote Dekstop Web
Connection package is available from Microsoft for installation on Win2K IIS or can be installed
on WS2K3 by selecting Add/Remove Windows Components, Application Server (details), IIS
(details), World Wide Web Service (details), Remote Desktop Web Connection. The former
installs in C:\inetpub\wwwroot\tsweb by default, and the latter installs in C:\windows\web\tsweb.
As you can see in Figure 2.15, the only options available in the default interface are Server name,
window size, and logon information (username and password). The Remote Desktop Web
Connection’s ActiveX control actually supports the full range of options available in the local
client, you just need a little programming skill to take advantage of them. The interfaces
available to the control can be found by searching http://MSDN.Microsoft.com for Remote
Desktop ActiveX Control Interfaces.

In the Appendix, I’ll offer an example of how to add an Experience drop-down box to the default page.

43
 Chapter 2

Figure 2.15: The Remote Desktop Web Connection interface.

Remote Desktops Administrative Tool

In addition to the two user-focused clients, WS2K3 includes a new version of the Terminal
Services Connections tool from Win2K. The new tool is called simply Remote Desktops, and
can be found in the Start menu under Administrative Tools. You can also install this tool on
WindowsXP by using the adminpak.msi package found on the WS2K3 source CD-ROM.
Figure 2.16 shows the Remote Desktops tool with a number of connections defined. By using
this tool, an administrator can store connection definitions to all servers in one interface. The tool
can even be used to connect to Win2K servers in Remote Administration or Application Server
mode or even WindowsXP desktops with Remote Desktop enabled.

44
 Chapter 2

Figure 2.16: The Remote Desktops administrative tool.

When you select one of the defined connections, the desktop of the server is displayed in the
right pane. You can establish connections to multiple servers and toggle between them by
selecting their icons on the left pane. The tool will even allow you to store credentials or select a
program to run in lieu of the desktop.

If you prefer to work with your terminal server connections in separate windows, you can mimic the
function of the Remote Desktops tool by creating a folder containing all of your RDP files and create a
shortcut to the folder on your desktop or Start menu.

Summary
In this chapter, I walked you through the process of installing and configuring the terminal server
role. I gave you an overview of the new settings available in the Terminal Services Configuration
and Group Policy editor tools. Next, I explored the clients available to connect with terminal
servers.
In Chapter 3, I will introduce you to a new load-balancing technology available in WS2K3—
Session Directory. I will also discuss other load-balancing options and talk about server sizing
and capacity. Finally, we will briefly explore a new concept in terminal server design: using
virtual machines to host terminal servers.

45
 Chapter 3

Chapter 3: Load Balancing and Session Directory

If you have more users than a single terminal server can support or you need the ability to take a
server offline for maintenance or application installations without impacting availability, load
balancing will become an integral part of your Terminal Services architecture. In this chapter, I
will introduce you to the native Microsoft Network Load Balancing (NLB) service. I will also
cover a new feature of WS2K3—Session Directory—which enables Windows to track user
sessions across multiple servers so that users can reconnect to the sessions when needed.
I’ll begin by introducing you to the basics of terminal server hardware configuration, then we’ll
explore terminal server sizing. This foundation of information will enable you to determine how
many servers you need to support your users’ needs.

Terminal Server Hardware Configuration

When you get right down to it, terminal servers are more like workstations than servers. How
many file and print servers have you encountered that have Microsoft Office installed on them?
System integrators need to keep this idea in mind when configuring hardware for a terminal
server.
Most file, print, and Web servers are configured to optimize disk access to improve performance
when users read and write files on the server and to separate the data from the OS to enable easy
backup and restore. Terminal servers, however, do not store data; they serve applications. So
other than an image capture of the server for disaster recovery and System State backups
between application installs, terminal servers do not require regular backups. If there is no data
on the server, what are you going to back up?
That being said, terminal servers need to be optimized for the applications they serve. Disk reads
need to be optimized, as the executables and DLLs of the applications are accessed by the user
sessions. Memory and processors need to be sized to handle the demands of multiple instances of
applications across user sessions. It is memory and processor power that are typically the
limiting factors of terminal server capacity—not disk space.
The application packages also come into play—most application installers are written for
workstations, so they default to installing to the C drive under the Program Files directory. In
fact, even today, there are still applications in popular use that will not even recognize a drive
other than C as a valid installation destination. So if your normal server configuration assumes a
D drive for data storage, that partition will end up being wasted space on a terminal server.

If you want to separate your applications from your OS by moving the Program Files directory to the
D drive, be sure to update the following registry value to reflect the new location—
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir. You
may also need to create custom transforms or installation scripts if you are automating your
application installs.

46
 Chapter 3

Hard Disk Configuration

As you might have determined by now, it is my recommendation that you configure your
terminal servers with a single logical drive. Doing so simplifies application installation, more
closely parallels a typical workstation configuration, and eliminates empty drive partitions. But
even with a single logical drive configuration you still have options when it comes to the
redundant array of independent disks (RAID) level. The RAID level you select is determined by
the number of physical disks you have in the server, and the level of disk fault tolerance you
require.
RAID level 0(zero), which Figure 3.1 illustrates, is defined as disk striping without parity. RAID
0 is not fault tolerant—losing a single disk results in all data being lost and the server will go
down, so it should never be used in mission-critical environments. The main benefit of RAID 0
is very fast disk reads and writes. Performance can be further increased by placing each drive in
the array on a separate controller, thus allowing blocks on each drive to be written
simultaneously. Despite its increased performance, this configuration is not recommended for
terminal servers as a result of its lack of fault tolerance.

Figure 3.1: RAID 0.

Figure 3.2 shows RAID 1—disk mirroring. RAID 1 is the most common form of RAID, as it is
very simple to implement, only requires two disks, and is fault tolerant. RAID 1 doubles the
disk-read speed of the server, but does not improve disk-write speed. In RAID 1, all data is
written on both drives in the mirror. If one drive goes down, the server can continue to operate
using the other drive. RAID 1 is a good option for terminal servers if you are limited on the
number of drives available.

47
 Chapter 3

Figure 3.2: RAID 1.

RAID 5, which Figure 3.3 shows, is also a very common array configuration. RAID 5 is defined
as disk striping with parity. As in RAID 0, data is broken up across the disks in the array, but
RAID 5 adds parity blocks distributed across the drives. The parity blocks can be used to
calculate a missing block if one of the drives fails. Thus, RAID 5 is single-disk fault tolerant.
Because data is distributed across multiple drives, read speed is increased dramatically; however
write speed is decreased slightly as the controller must calculate the parity block for each unit of
data (that is, two reads and two writes are required for each block written). RAD 5 requires a
minimum of three disks and is a good option for terminal servers. RAID 5 is also the most cost-
effective RAID option offering fault tolerance.

Figure 3.3: RAID 5.

If you use RAID 5 and you lose a drive, the server will continue to operate for your users, but disk-
read speed will be dramatically reduced as the controller must calculate the missing block for every
chunk of data.

48
 Chapter 3

RAID 10 (sometimes called RAID 1+0) combines the speed of disk striping with the fault
tolerance of disk mirroring. This RAID level, which Figure 3.4 shows, is a RAID 0 array, but
each element of the array is actually two mirrored drives. RAID 10 provides the fastest disk
access of the RAID levels while still maintaining fault tolerance. In fact, under RAID 10, you
can lose multiple drives and still be operational (as long as you don’t lose both the drives that
make up a mirror). The disadvantage of RAID 10 is that you lose half of your disk space to fault
tolerance; however, because a lot of drive space is not usually a requirement for a terminal
server, so this potential drawback is not an issue (you are not storing data on the server). RAID
10 is an excellent choice for terminal servers that have at least four drives.

Figure 3.4: RAID 10.

At first glance, RAID 0+1 looks very similar to RAID 10 (see Figure 3.5). The difference is in
how the disk controller treats the array. Instead of being a RAID 0 array with each element being
mirrored, RAID 0+1 is treated as a RAID 0 array where the entire array is mirrored as a unit.
Thus, unlike RAID 10, RAID 0+1 can only lose a single drive and maintain operation. The
reason is that once a drive fails, the controller will take the entire RAID 0 array that contains that
drive offline and continue to operate as a single RAID 0 array. RAID 0+1 is an excellent option
for terminal servers, as it dramatically increases disk operations while maintaining fault
tolerance. The determination is usually made by the disk controllers you use in your servers.
Most controllers support either RAID 10 or RAID 0+1 but not both.

Figure 3.5: RAID 0+1.

49
 Chapter 3

Memory
When RAM was more expensive, memory often became the limiting factor in terminal server
sizing. Today, it is fairly common to see terminal servers with 4GB of RAM—enough to handle
hundreds of heavy user sessions. The amount of RAM in a server is more often limited by the
OS and server hardware than the budget.
The first thing to consider when sizing memory for your server is the memory limitations of the
motherboard and BIOS. You also want to pay attention to the number of RAM slots available,
and purchase RAM in appropriate sizes. The edition of WS2K3 you choose also limits the
amount of memory you can use. Table 3.1 shows the maximum RAM and processors for each
edition.
Edition Maximum RAM Maximum Number of
Processors
Standard Edition 4GB 4
Enterprise Edition 32GB 8
(32-bit)
Datacenter Edition 64GB 32
(32 bit)

Table 3.1: Maximum memory and processors for Server 2003 editions

It is one thing to just throw RAM into a server; it is yet another to accurately judge the amount of
memory that your users need. Luckily, there are a number of resources available to assist in
estimating the amount of RAM required to support users on a terminal server.
When Win2K was launched, Microsoft, NEC, and Groupe Bull teamed up and produced a white
paper to help you determine your servers’ memory needs. This document is still quite relevant
and helpful for sizing WS2K3 terminal servers. In fact, you can see how the results of this study
influenced Hewlett-Packard (HP) in its HP ProLiant Sizer for Citrix MetaFrame XP and
Windows Server 2003 Terminal Services—an online tool for sizing HP servers for Terminal
Services.

You can find the complete text of the white paper “Windows 2000 Terminal Services Capacity and
Scaling” at http://www.microsoft.com/windows2000/techinfo/administration/terminal/tscaling.asp.
The HP ProLiant Sizer for Citrix MetaFrame XP and Windows Server 2003 Terminal Services tool is
available http://activeanswers.compaq.com/ActiveAnswers/Render/1,1027,4825-6-100-225-1,00.htm
(registration required).

Microsoft recommends starting your memory requirement calculations with 128MB of RAM for
the OS. After that, you need to determine the type of work your users will perform on the
terminal server. The Groupe Bull study divides workers into three categories:
• Structured task workers—Users who tend to use one application at a time in a sequential
task-oriented process. These users are typically fast typists (about 60wpm) and are only
partially dependant on computer availability. These users typically work in claims
processing, account processing/accounts receivable, or customer service.

50
 Chapter 3

• Knowledge workers—Users who are dependent on their computers to get work done.
These users tend to use multiple applications simultaneously, toggling between them.
Their workflow is more ad hoc rather then sequential. These users are the executives,
project managers, and analysts.
• Data entry workers—Users who input data into computer systems, such as transcription
typists, order entry clerks, clerical workers, and manufacturing personnel.
HP’s ProLiant Sizer tool uses the following user types:
• Light Users—Users of single–line-of-business applications. An example of a light user is
a call center agent who uses a customer satisfaction database application.
• Medium Users—Users of basic office productivity applications such as word processors
and spreadsheets; office administrators are typical medium users.
• Heavy Users—Users who have higher graphics requirements, do extensive Internet
browsing, or send and receive a significant amount of email.
Once you determine the type and number of concurrent users your terminal servers must support,
you can use Table 3.2 to calculate the amount of memory your terminal servers will need.
User Type Memory Per User System Memory Total Memory
Structured task worker 9.3MB 128MB System + (number of
users × memory per
user)
Knowledge worker 8.5MB 128MB System + (number of
users × memory per
user)
Data entry worker 3.5MB 128MB System + (number of
users × memory per
user)

Table 3.2: Terminal server memory requirements for user types.

The ProLiant Sizer tool goes a step beyond the Groupe Bull study and allows you to factor in
additional memory for Advanced Heavy Users and 16-bit applications. 16-bit applications
require additional RAM because in addition to the memory requirements of the application, you
need to allocate RAM to the Windows 16-bit virtual machine subsystem—WOW.EXE. This
addition can add as much as a 25 percent overhead in memory use compared with a 32-bit
version of the same application.

Processor
Terminal servers support multiple concurrent users, and multiple concurrent users means
multiple concurrent processes and threads. As a result, the demands placed on the processor in a
terminal server can be quite high. So having the ability to process multiple threads
simultaneously vastly improves the performance of a terminal server. Thus the reason why most
terminal servers are multiprocessor servers, allowing the system to run a thread on each of the
processors concurrently.

51
 Chapter 3

As you saw in Table 3.1, each edition of WS2K3 has a limit on the number of processors it can
support. The processor limits of WS2K3 appear to be the same as those of Win2K Server, but
WS2K3’s native support for HyperThreading introduces a significant difference.
HyperThreading is a new processor technology introduced by Intel in 2002. This technology
allows a single processor to handle two threads in parallel, virtually doubling the computing
power of the processor.
The difference in the processor limits between the two OS versions comes from WS2K3’s ability
to distinguish between a physical processor and a virtual one created by HyperThreading. When
Windows boots, the OS counts the number of processors in the system. If there are more
processors than the OS is licensed to support, the OS will stop counting at the OS limit. It is
important to note that the computer’s BIOS enumerates physical processors before virtual ones.
This behavior prevents Win2K from using virtual processors when there are still available
physical ones. Figure 3.6 shows the order in which processors are counted by the OS when using
HyperThreading.

Figure 3.6: The order that processors are counted when using HyperThreading.

Let’s compare the processor limits of the Standard Edition of each OS—each is limited to four
processors. Because Win2K can not distinguish between physical and logical processors, the OS
will stop at the fourth processor. In the example that Figure 3.6 shows, where there are four
physical processors with HyperThreading, Win2K will stop at processor four and only place one
thread on each processor. If there were only two physical processors with HyperThreading,
Win2K would still stop at the fourth processor, but in this case, that would place two threads on
each processor by taking advantage of the HyperThreading technology.
WS2K3, however, is capable of distinguishing between physical and logical processors and
applies its processor limit only to physical processors. Thus, in the scenario that Figure 3.6
illustrates, WS2K3 would take advantage of all eight logical processors, thus doubling the
computing power over Win2K on the same server.

52
 Chapter 3

What does this mean for terminal servers? In many cases, WS2K3’s support for HyperThreading
will enable you to see an increase in performance without having to add processors or upgrade to
the Enterprise Edition of Windows. HyperThreading may also influence the class of server
hardware you use. You may be able to purchase dual- or quad-processor hardware where you
used to select 8-way systems.

The Bottom Line

When you put all this information together, the question that you will be attempting to answer is
“How many users will a terminal server support?” Of course, there are a number of variables that
go into the answer—the number of applications each user will employ on the server, the memory
and processor requirements of each of the applications, and the frequency with which the users
toggle between the applications. To clarify, let’s explore an example based on current server-
class hardware.
Let’s start with a dual-processor server that has 2.4GHz Xeon processors with HyperThreading
enabled. Next, we’ll add 2GB of RAM and four SCSI hard drives in RAID 10 configuration.
Such a server would probably cost around $6000 retail. Based on the Groupe Bull study, this
server would support as many as 200 Heavy/Structured task workers. If you are using the same
server to publish a single application to your users instead of a full desktop environment, the
same server may support as many as 400 concurrent users (depending on the requirements of the
application).
If your terminal server desktop environment contains standard productivity applications—
Microsoft Office, Outlook, Internet Explorer (IE), and so on—your limiting factor in this
example is memory; the dual HyperThreading processors will not be running at capacity. So by
simply doubling the RAM to 4GB, you could also double the number of concurrent users.

There are also third-party utilities, such as Wyse Expedian (http://www.wyse.com), that optimize
memory use on terminal servers, allowing you to increase the capacity of your servers even further.

Fault Tolerance
Fault tolerance—The ability for a system to continue to function after one of its
components has failed.
I’ve already talked about ensuring hard disk fault tolerance by using RAID, and most server-
class hardware provides options for redundant power supplies and network interface cards
(NICs). In addition to ensuring fault tolerance in your hardware, you will want to consider the
amount of fault tolerance you require at a server level. This decision will be based on how
mission critical your terminal servers are:
• Server fault tolerance—This level of fault tolerance determines the ability to continue to
support your users after losing a single server. To provide server fault tolerance, you
calculate the number of servers required to support your users, then add one spare server.
You still load balance across all servers, but maintain the capacity needed even if one
server is offline.

53
 Chapter 3

• Location fault tolerance—This level of fault tolerance determines the ability to continue
to support your users after losing all servers in a given location. This server loss can be
the result of a failure in network connectivity, a building emergency, or a natural disaster.
To provide location fault tolerance, you calculate the number of servers required to
support your users, distribute them across your locations, then add spare servers equal to
the number of servers in a single location. The spare servers are also distributed across
locations.
In many cases, you may not need to provide enough fault tolerance to support all of your users
during an outage—only critical users. To make the right decision about the amount of fault
tolerance you need requires adequate data gathering; talking to management and your users to
determine the number of mission-critical users and to assess the business impact of an outage.
Figure 3.7 illustrates an example comparison of server and location fault tolerance. In the
example, there are 1200 mission-critical users. For server fault tolerance, this number of users
would require four servers, each able to handle 400 concurrent users. During normal conditions,
each server would only have 300 users, but in the event of a server outage, the remaining three
servers could still handle the load. For location fault tolerance, with two buildings used to house
servers, you would need 6 × 400 user servers. This way, if Building 1 were unreachable, the
three servers in Building 2 could continue to support your users.

Figure 3.7: A comparison of server and location fault tolerance.

54
 Chapter 3

You should also consider usage schedules in your design. If your users work 24 hours a day 7
days a week, you will need to provide adequate capacity to allow you to take a server or servers
offline for maintenance and new software installs. However, if your users work a 9-to-5
schedule, you will be able to perform maintenance in the evenings, thus saving you the cost of
additional servers.
Once you determine the number of servers required to support your users and provide adequate
fault tolerance, you then need a way to distribute user sessions across the servers. Enter load
balancing.

Load Balancing
The most basic form of load balancing is done manually. You create separate connection files for
each of your servers and distribute the files to your users, telling percentages of users to use a
specific connection file as their primary. Going back to the example that Figure 3.7 shows, if you
have 1200 users and four servers, you would create four connection files, give all four files to the
users, but instruct 400 users to connect to server A, 400 to connect to server B, and so on. If one
server goes down, users can then use another connection file as a backup. If you want your load
balancing and failover to be automatic and not rely on users to remember a different procedure
for failure scenarios, you will need to implement a load balancer of some kind.

Microsoft Network Load Balancing

NLB enables you to place a group of servers behind a virtual IP (VIP) address. NLB distributes
connections made to the VIP among the servers in the cluster and maintains intra-server
communication so that if a server becomes unavailable, NLB will stop directing clients to it.
In WS2K3, Microsoft has continued to evolve its native load balancer. Under Win2K, NLB was
only available in Advanced and Datacenter editions. WS2K3 includes NLB in all four editions.
In addition, Microsoft has included the following enhancements:
• NLB Manager tool—Win2K requires that you configure each server in the NLB cluster
manually, which makes setting up a cluster very tedious and increases the opportunity for
error. WS2K3 includes a new administrative tool that enables you to centrally create,
configure, and control NLB clusters.
• Virtual clusters—When using NLB for clustering Web servers, you can create multiple
clusters on the same set of servers by utilizing multiple IP addresses on each server. Each
virtual cluster is represented by its own VIP.
• Multi-NIC support—WS2K3 allows you to bind NLB to every NIC in the system.
Win2K only allowed NLB to be bound to one NIC on the server.
• Multicast support—WS2K3 NLB clusters can be configured to use multicast for intra-
server communication.

55
 Chapter 3

Even with these enhancements, NLB still has limitations that you must consider in your design.
First, all members in an NLB cluster must be in the same subnet. If you need to distribute your
terminal servers across more than one subnet (for location fault tolerance perhaps), you will have
to create a separate cluster for each subnet and design a way to load balance across the clusters.
Second, NLB only considers the number of active connections to the server when determining
which member server to direct a connection to; it does not have any way to measure the amount
of memory or processor in use. Third, when used with a Session Directory, NLB requires that the
IP addresses of the terminal servers must be visible to clients; it does not support routing tokens.
Also, NLB is limited to 32 nodes in a cluster.

Within the NLB Manager tool, Microsoft refers to a group of load-balanced servers as a cluster. Do
not confuse this terminology with true server clustering, which allows servers to share processes and
storage to effectively act as a single server. Most documentation on load balancing, including many of
Microsoft’s own white papers, refers to load-balanced groups of servers as farms. In this book,
however, I will use the term cluster to be consistent with the NLB Manager tool.

Configuring NLB
Once your terminal servers are configured and your applications installed, you are ready to begin
configuring them for NLB. Before you begin, you will want to gather the following information:
• The VIP address you have selected to represent the cluster
• The unique IP addresses of each server in the farm
• The Domain Name System (DNS) alias you want to use for the cluster
• The network protocol and port on which you want to load balance (for RDP, this port is
TCP port 3389).
• A domain account with administrate rights to all servers in the cluster, or the local
administrator account and password for each server
After gathering this information, you should launch the NLB Manager tool. You can do so from
any WS2K3 system or from a Windows XP client with the WS2K3 Administrative Tools
installed.
The NLB Manager tool, which Figure 3.8 shows, lets you create, configure, and manage NLB
clusters on the network. In this window, you will want to create a new cluster by selecting New
from the Cluster menu.

56
 Chapter 3

Figure 3.8: The NLB Manager tool.

You will then be presented with the Cluster Parameters dialog box, which Figure 3.9 shows. In
this window, you will enter the VIP address for the new cluster, the subnet mask, and the DNS
name of the cluster. If you plan to do all management of the cluster through the NLB Manager
tool, you do not need to enable remote control or set a password. NLB Manager uses the
Windows Management Interface—WMI—so it uses the user’s credentials to make changes to
the servers in the cluster.

57
 Chapter 3

Figure 3.9: Configuring cluster parameters.

You can also select whether intra-server communication is done using unicast or multicast. If
each of your terminal servers has only one NIC, and your network supports multicast within the
subnet, you should enable multicast. Doing so allows you to manage the cluster through NLB
Manager running on any of the servers in the cluster. After filling out your cluster’s parameters,
click Next.

For additional information about enabling multicast support, see the NLB Clusters Help topic or the
“Technical Overview of Windows Server 2003 Clustering Services” white paper found at
http://www.microsoft.com/windowsserver2003/techinfo/overview/clustering.mspx.

The next window of the NLB Manager tool asks you for any additional IP addresses used in the
cluster. This information is typically used for load balancing Web servers, where each server
hosts multiple Web sites, each represented by a unique IP address. For terminal servers, you can
leave this page blank, and click Next to bring up the Port Rules dialog box.
Port rules are used to determine how connections to the VIP are handled. The default rule states
that all TCP and UDP traffic is distributed equally among the cluster nodes. For terminal servers,
you only need to load balance RDP, so highlight the default rule, and click Remove. Then click
Add to bring up the Add/Edit Port Rule window (see Figure 3.10).

58
 Chapter 3

Figure 3.10: Editing a port rule in NLB Manager.

In this window, you will set the port range as From 3389 To 3389, and specify TCP as the
protocol. This configuration will only load balance connections made by RDP. By limiting your
port rule to RDP, you reduce overhead on your NLB service and on your node servers by
shielding them from erroneous connections made to the VIP on other ports.
You should leave the filtering mode set to the default (multiple host, single affinity), but the
following list provides information about the options available:
• Multiple host—With this setting selected, connections made to the specified port range
will be load balanced across multiple nodes. When selecting multiple host filtering, you
must also select an affinity mode. Affinity ensures that once a client is directed to a
specific node, the client continues to be directed to that same node for all communication
during the session. The affinity options are:
• None—No affinity is used.
• Single—Affinity is based on the IP address of the client; load balancing is
performed on a per-client basis.
• Class C—Affinity is based on the Class C subnet of the clients; once a single
client establishes a connection to a specific node, all connections from that subnet
will be directed to the same node.

59
 Chapter 3

• Single host—Connections made to the specified port range will be directed to a single,
specific node, unless that node is unavailable, in which case connections are made to the
next node calculated by Handling Priority number. The Handling Priority for the node
number is set when you add a server to the cluster. This option is used to create server
fault tolerance without load balancing.
You can also disable the rule in this window. Doing so allows you to temporarily disable load
balancing of a specific port range without having to delete and re-create the rule.
After configuring your port rules, click Next to proceed to the Connect window (see Figure
3.11). In this dialog box, you enter the name of the first server to be added to the cluster. The
NLB Manager tool will establish a connection to this server and display a list of the configured
network adapters. You should select the adapter from which you want to accept incoming
connections from the VIP, and click Next.

Figure 3.11: Adding the first server to a new NLB cluster.

In the resulting Host Parameters window (see Figure 3.12), you configure the specific server you
have selected to join the cluster. In this window, you first set the priority number, which is used
both as a unique identifier for the node and for failover order in a single host filtered cluster. You
can change the physical IP address of the server and its subnet mask if needed, and set the
default state for the load-balancing service when the server boots.

60
 Chapter 3

Figure 3.12: Configuring host parameters for an NLB cluster node.

After clicking Finish, the NLB Manager tool will connect to the server using WMI and configure
the NLB service. You will be returned to the main NLB Manger window where you will see
your newly created cluster. In this window, you can right-click the cluster to add hosts. Each
time you add a server, you will be required to select a network interface and set a priority
number for the node.
When you are done adding the remaining terminal servers to the cluster, you can test NLB by
using the Remote Desktop Connection client to connect to either the VIP address or the DNS
name of the cluster. Your connection should be routed to a specific server in the cluster, and you
will be prompted with the logon screen for that server.

To connect to the DNS name of the cluster, you must either have Dynamic DNS (DDNS) running in
your network, which allows the NLB service to register the cluster name, or manually add the cluster
alias to your DNS database.

61
 Chapter 3

Third-Party Load Balancers

Although Microsoft NLB is robust, easy to configure and manage, and is free with all editions of
WS2K3, there are many reasons to consider a third-party load balancer for your terminal server
environment. Perhaps you need to distribute your servers across multiple subnets. Or you need
more that 32 servers to support the number of users in your environment. Maybe you are using
Session Directory and want to enable connection tokens so that you can hide the physical IP
addresses of your terminal servers from your users. (We’ll explore Session Directory in more
detail in a moment.) Or your company may simply have a standard product and infrastructure for
load balancing. Regardless of the reason, there are many excellent load balancers on the market.
One major factor that may place one load balancing product ahead of the rest is how it
determines load. With many load balancers—Microsoft NLB included—load is simply the
number of active connections to a node. In a terminal server environment, this method of
measure is not always adequate. Perhaps you have a mixture of Heavy, Medium, and Light users
in your environment. If load is calculated purely by the number of open connections, you have
no way of preventing one server from handling more Heavy users than the rest—it is purely the
luck of the draw.
Some load-balancing products are able to place metrics on the node servers and determine load
based on available memory, processor utilization, or other performance factors. These types of
products are a great advantage when load balancing terminal servers as they keep the actual
performance of your servers at an equal level, even if that means that one server is handling more
users than another.

In addition to load balancers, there are also third-party products specifically designed to enhance
Terminal Services. These products not only handle load balancing, but also allow you to publish
applications, making it easier for your users to connect to a specific application rather than a terminal
server desktop. The two leading products are Citrix MetaFrame (http://www.citrix.com) and New
Moon Canaveral iQ (http://www.newmoon.com).

Session Directory
One of the challenges of creating a load-balanced cluster of native Windows terminal servers is
how to deal with disconnected sessions. As we explored in Chapter 2, administrators have the
ability to configure timeouts for idle and disconnected sessions on a terminal server. You can
either set these timeouts very low, giving only enough time for a user to reconnect from the same
client device and IP address in the event of a network failure, or you can set it fairly high, giving
your users the ability to disconnect from a session, leave applications running, then reconnect at
a later time to pick up where they left off.
These settings work perfectly well in a single server environment. When the user reconnects to
the server, Session Manager reconnects them to his or her existing session. If, however, you have
a load-balanced cluster of terminal servers, Session Manager is unaware of sessions on the other
servers in the cluster. Microsoft addresses this challenge in WS2K3 with Session Directory.
The Session Directory server maintains a dynamic database that maps user names to open
sessions on all terminal servers in the cluster. This feature enables users to be reconnected to
existing sessions on any server in the cluster, regardless of which server the NLB service initially
directs/connects them to.

62
 Chapter 3

Configuring Session Directory

To take advantage of the Session Directory feature, all terminal servers in the cluster must be
running WS2K3 Enterprise or Datacenter edition. The Session Directory server can use any
edition of WS2K3. You can even create the Session Directory on one of the terminal servers in
the cluster, although it is not recommended because that would prevent you from taking that
terminal server offline for software installations/upgrades without impacting the entire cluster.
To configure Session Directory, begin with the server you want to host the session database. On
this server, open either the Computer Management or Services administrative tool to access the
Terminal Services Session Directory (among the available services) Go into this service’s
properties, set the startup type to automatic, and start the service (see Figure 3.13).

Figure 3.13: Enabling the Terminal Services Session Directory service.

The first time the Session Directory service is started, it will create a new local group on the
server called Session Directory Computers. For a terminal server to inform the Session Directory
server of the terminal server’s sessions or query the Session Directory for sessions on other
servers, the terminal server must be a member of this group. You can either add the individual
computers in the cluster to the group or create a domain group containing the terminal servers
and add that group to Session Directory Computers.
Once your Session Directory server is set up, you will then need to configure the terminal servers
to take advantage of it. You can do so with either the Terminal Services Configuration tool or the
Group Policy Object Editor. On WS2K3 Enterprise or Datacenter editions, the Server Settings
node of the Terminal Services Configuration tool has an additional option—Session Directory.
Figure 3.14 shows the properties page of this setting.

63
 Chapter 3

Figure 3.14: Session Directory settings for a terminal server.

Here you enter the cluster name of the NLB cluster to which the terminal server belongs and the
host name or IP address of the Session Directory server. If your terminal server has more than
one network interface, you must select which one to redirect client connections to. You must also
specify whether to instruct clients to reconnect to the unique IP address of this server by
checking IP address redirection or to use routing token redirection if the server IP addresses are
not visible to the clients.

If you are using Microsoft NLB, you must select IP address redirection, as NLB does not support
routing tokens.

If you choose to use the Terminal Services Configuration tool, you will have to configure the
same settings on every terminal server in the cluster individually. If you are in an Active
Directory (AD) environment, using Group Policy to configure your servers is a much simpler
option as it reduces the chance for error and gives you a single location to make changes if
needed.
To use Group Policy to configure your terminal servers for Session Directory, create or edit a
GPO that applies to all terminal servers in the cluster. Then, in the Group Policy Object Editor,
navigate to Computer Configuration, Administrative Templates, Windows Components,
Terminal Services, Session Directory, as seen in Figure 3.15.

64
 Chapter 3

Figure 3.15: Session Directory Group Policy settings.

From this point, you can access settings that match those in the Terminal Services Configuration
tool. Enable all four settings and enter the required information. At the next policy refresh
interval, all servers in the cluster will be configured to take advantage of Session Directory. By
using Group Policy to configure Session Directory, you make the task of adding servers to the
cluster much easier because you will not need to configure each server individually; they will
simply inherit the settings from the GPO.

When using Session Directory, the server hosting the database becomes critical to the operation of
your terminal servers. You might want to take advantage of Windows clustering to make your Session
Directory fault tolerant. Microsoft includes instructions about how to do so in the white paper “Session
Directory and Load Balancing Using Terminal Server” at
http://www.microsoft.com/windowsserver2003/techinfo/overview/sessiondirectory.mspx.

How Session Directory Works

The following section provides an example scenario to give you an idea of how Session
Directory works. In the morning, Joe User uses the Remote Desktop Connection client to open a
connection to TSCluster.Domain.Com—the DNS alias of the NLB cluster that Figure 3.16
shows. The NLB service directs the connection to TServer02, the least loaded server at that time.
Joe logs into TServer02, and because Joe does not have an existing session on TServer02, the
server queries the Session Directory service for any existing sessions belonging to Joe User on
any other servers in the cluster. Joe does not have any other sessions, so TServer02 accepts the
connection, and Joe gets to work.

65
 Chapter 3

Figure 3.16: An example Session Directory architecture.

Around 3:00, Joe decides that he is going to head home and continue working from there. He is
in the middle of a document, and has three Web browsers open for reference material, so he
disconnects from the session rather than logging off. This way, he can pick up right where he left
off when he gets home. When Joe disconnects from his session, TServer02 informs the Session
Directory server of the disconnected session. The Session Directory server creates an entry in the
database that lists Joe’s username and domain, the server hosting the session, the time the session
was created and disconnected, and the resolution and color depth of the session.
At home, Joe establishes a virtual private network (VPN) connection to the corporate network.
He launches the Remote Desktop Connection client on his home computer, and enters
TSCluster.Domain.Com. The NLB service directs the connection to the unique IP address of the
server node with the least number of active connections—this time it is server TServer01. Joe is
then presented with the logon screen for TServer01 and enters his credentials.
TServer01 first checks its own list of disconnected sessions to see whether Joe has a session to
reconnect with. When it finds none, TServer01 then queries the Session Directory database. The
database finds a session listed for Joe on server TServer02, so it sends Joe’s Remote Desktop
Connection client the IP address of TServer02 and Joe’s encrypted credentials.
The Remote Desktop Connection client then automatically connects to TServer02, and sends the
credentials. TServer02 finds that Joe has an existing session and reconnects Joe, who happily
continues to work on his document.

66
 Chapter 3

Summary
When designing a terminal server infrastructure for a large number of users, there are several
factors to be considered. In this chapter, I covered terminal server sizing, which will enable you
to determine how many concurrent users a given server will handle. I then talked about the
different levels of fault tolerance, which may impact the number of servers you use.
Once you determine how many servers are required, you then need a way to distribute client
connections across the servers. This chapter introduced you to the Microsoft NLB service—the
native option for distributing connections across a cluster of servers.
Finally, I covered WS2K3’s new Session Directory service, which enables you to ensure that
users get reconnected to disconnected sessions regardless of which server in the cluster they
connected to initially. By using these techniques and technologies together, you can create a
large, fault-tolerant set of terminal servers ready to accept connections from thousands of clients.
In Chapter 4, I will cover the techniques and tools used to administer and manage your terminal
servers and the user sessions on them. I will cover common administrative tasks, from
configuring user profiles to assisting users via remote control. I will also cover some advanced
techniques for managing servers within a load-balanced cluster, and provide some helpful scripts
for automating repetitive tasks.

67
 Chapter 4

Chapter 4: Terminal Services Administration

As with any technology deployment, the process of installing and configuring your terminal
server is only half the work. You must also plan for ongoing administration and maintenance and
software life cycle management. In this chapter, we’ll focus on Terminal Services
administration, including user account configuration and management. In addition, we’ll explore
GPO-based configuration from an AD perspective. I will introduce you to loopback policy
processing, the creation of custom administrative templates, and the domain policy processing
order. I will also walk you through some common terminal server administrative tasks and
introduce you to the tools—both GUI and command line—used to manage terminal servers and
user sessions. Let’s start by jumping into user account administration.

Terminal Server Access Requirements

WS2K3 has three distinct layers of protection that enable you to control who can log on to a
terminal server. For a user to log on to a terminal server, these settings must be in place:
• The Allow log on through Terminal Services right—Under Win2K, you are required to
grant the Log on locally right to all users who need access to a terminal server. This
requirement poses a potential security hole as it allows users to log on at the console of
the server, thus bypassing any restrictions you configured for RDP. WS2K3 separates the
right to log on to the console from the right to log on through Terminal Services. By
default, on WS2K3, the Allow log on through Terminal Services right is granted to
Administrators and to the Remote Desktop Users group.
• Permission to use RDP—An administrator can set permissions on RDP through the
Terminal Services Configuration tool. As I mentioned in Chapter 2, Microsoft’s new
focus on security has changed the default permissions for the protocol in WS2K3. Under
Win2K, the local Users group is granted access to RDP; WS2K3 restricts this right to the
local Remote Desktop Users group. Thus, you must add your users to this group in order
for them to log on to the terminal server.
• The Allow logon to terminal server check box—In the properties of each user object in
AD, there is an Allow logon to terminal server check box that controls whether the user is
enabled to log on to a terminal server. This check box is selected by default.
Two of the three settings are dependent on membership in the Remote Desktop Users group. If a
user receives a You do not have permission to access this session error message, one of these
three settings is the culprit. In the following sections, I will explain how and where to adjust
these settings.

Allow Log On Through Terminal Services

You can control the Allow log on through Terminal Services right through either the Local
Security Policy administrative tool or the GPO editor (GPEDIT.MSC), under Security Settings,
Local Policies, User Rights Assignment. When you install the Terminal Services role, this right
is granted to the local Remote Desktop Users group. Figure 4.1 shows the default groups that are
granted this right.

68
 Chapter 4

Figure 4.1: Groups assigned the Allow log on through Terminal Services right by default.

If your terminal server is in an AD domain, the Local Security Policy editor will show both the
local setting and the effective setting, as user rights assignment can be controlled through domain
GPOs. If you find that the effective setting does not grant the required users this right, you will
need to use the Resultant Set of Policy tool (RSOP.MSC) to determine which GPO is revoking
the right.

Even on WS2K3, the Log on locally right is open to both Administrators and users. If your terminal
server is in an unsecured location, you can restrict this right to Administrators only, and only allow
users to access the server over Terminal Services.

Permissions on RDP
In Chapter 2, I introduced you to the Terminal Services Configuration tool, and focused on how
you can use this tool to tune the server for optimal performance and to configure user session
timeouts and resource redirection settings. You can also use this tool to set permissions on RDP.
As the Permissions tab of the properties of the RDP-Tcp connection shows (see Figure 4.2),
permission to use RDP is restricted to Administrators and the Remote Desktop Users group. By
default, the Remote Desktop Users group is empty, so you must add users or groups to it to
enable them to connect to your terminal server.

69
 Chapter 4

Figure 4.2: Setting permissions on RDP.

As you can see in Figure 4.2, the Remote Desktop Users group is granted User Access by
default. Each access level—guest, user, and full control—comes with a different set of
permissions over sessions on the terminal server. To fully utilize the power of these permissions,
you must first understand what each access level provides as well as which advanced settings are
available.

RDP Access Levels

RDP provides three basic levels of access: Guest Access, User Access, and Full Control. The
level assigned to a group determines the group’s abilities when connected to the terminal server
over RDP. Let’s first examine the permissions available, then associate them with the basic
access levels. Figure 4.3 shows the advanced ACL editor’s list of individual permissions, and
Table 4.1 explains which abilities each permission setting bestows on the users.

70
 Chapter 4

Figure 4.3: Permissions available for RDP.

Permission Ability
Query Information Query information through the Terminal Services Administrator or at a
command prompt using the QUERY command.
Set Information Change settings and permissions for RDP.
Remote Control View or actively control another user's session.
Logon Log on to a session on the server.
Logoff Force another user to logoff of his or her session.
Message Send messages to other sessions on the server by using the Terminal
Services Manager console or at a command prompt by using the MSG
command.
Connect Reconnect to a session that the same user left active on the server.
Disconnect Forcibly disconnect another user from his or her session, leaving the session
active on the server.
Virtual Channels Use virtual channels, which are communication channels that developers can
use to enhance the capabilities of RDP. As long as System has this
permission, users will be able to use applications that take advantage of
virtual channels.

Table 4.1: Permissions available for RDP.

71
 Chapter 4

Table 4.2 shows the permissions assigned to each basic access level. You can use the advanced
window of the ACL editor to create special permission sets. For example, you may want your
Help desk staff to have all the abilities of Full Control except Set Information.
Permission Guest Access User Access Full Control
Query Information X X
Set Information X
Remote Control X
Logon X X X
Logoff X
Message X
Connect X X
Disconnect X
Virtual Channels X

Table 4.2: Permissions associated with the basic access levels.

Allow Logon to Terminal Server

The last requirement to log on to a terminal server is a per-user setting. In the properties of every
user object, there are four tabs dedicated to terminal server settings. Most of the settings affect
session behavior when a user connects to a terminal server. I will cover these settings in the next
section. However, you can use the Allow logon to terminal server setting to restrict a user’s
ability to connect to your terminal servers altogether. Figure 4.4 shows this setting on the
Terminal Services Profile tab of the User Properties. This setting is enabled for all users by
default.

72
 Chapter 4

Figure 4.4: The Terminal Services Profile tab of a user object.

User Account Configuration

While we are focused on the User Properties interface, I’d like to take you through the rest of the
terminal server settings. Most of these settings are also available in the Terminal Services
Configuration tool. It is up to you to decide whether you want to control them on a per-server or
a per-user basis. Keep in mind that per-server settings override per-user settings. To access the
user-based options, use one of the following tools: for AD domains, use the Active Directory
Users and Computers tool; for NT 4.0 domains, use the User Manager for Domains tool; and for
Workgroup mode terminal servers, use the Computer Management Administration tool.

The Terminal Services tabs shown in this section do not appear in the NT 4.0 version of User
Manager for Domains; you must use the Win2K, WS2K3, or NT 4.0 Terminal Server Edition version
of the tool.

Regardless of the tool you use, the same options are available. Figure 4.5 shows the Environment
and Remote control tabs of the User Properties interface.

73
 Chapter 4

Figure 4.5: The Environment and Remote control tabs of the User Properties interface.

The Environment tab is used to configure both starting program and client device resource
redirection settings. You use the client device settings to enable or disable the automatic
connection to the client devices’ drives and printers. If you enable the Start the following
program at logon setting, whenever the user connects to any terminal server, he or she will
receive the specified program instead of a Windows desktop.

As with all of the settings in this section, server settings override user settings. Thus, if you specify a
starting program on the user account as well as one in the Terminal Services Configuration tool, the
program specified on the server will be launched.

On the Remote control tab, you can enable or disable the ability to remotely control sessions
belonging to this user. If you enable remote control, you can also specify whether to require the
user’s permission before the remote control connection is permitted as well as the level of
control the administrator has over the session once connected. Once again, these settings will be
overridden if remote control is configured on the server through the Terminal Services
Configuration tool.
The Sessions tab, which Figure 4.6 shows, allows you to set timeout values for the user’s
Terminal Services sessions. On this tab, you can set timeouts for active, idle, and disconnected
sessions. You can specify whether to immediately end the session when the connection is lost or
the active session time limit is reached or to treat the session as disconnected. You can also
specify whether the user can reconnect from any client device or only from the device that
originally started the session.

74
 Chapter 4

Figure 4.6: The Sessions and Terminal Services Profile tabs of the User Properties interface.

You use the Terminal Services Profile tab, which Figure 4.6 also shows, to set the profile and
home directory path to be used when the user logs on to a Terminal Services session. In addition,
this tab provides the settings to specify whether the user can log on to a terminal server at all.
Unlike the other settings in this section, the settings on this tab are not duplicated in the Terminal
Services Configuration tool.

Home and Profile Directories

As a systems administrator, you are probably familiar with network home directories and
roaming profiles. These features in Windows enable you to maintain central stores for your
users’ documents and profile settings so that the documents and profile settings are available
regardless of at which computer users sit.
Terminal Services has the ability to maintain separate stores for home and profile data for the
users. How you utilize this ability depends on your environment and administrative style.

Terminal Services Profile Path

When a user logs on to a workstation, the system checks the Profile Path attribute of the user
object to see whether the user has a centrally stored profile. If so and if it is newer than any
locally cached copy, the profile is downloaded for the user. In the same way, when a user logs on
to a terminal server, the system queries the UserParameters attribute and looks for a Terminal
Services Profile Path.

75
 Chapter 4

This separation enables administrators to maintain separate profiles for users depending on
which type of computer the users are accessing. In most cases, you will want to take advantage
of Terminal Services profiles, as certain functions of Terminal Services make it difficult to not
maintain Terminal Services profiles. Let me explain what I mean. If you do not use roaming
profiles for your users’ workstations, you rely on the fact that the computer maintains a copy of
the user profile. If your users do not log on to more than one PC, this setup is perfectly fine. On a
terminal server, however, not using roaming profiles means that the terminal server would be
maintaining the profiles for all your users, which would consume a lot of disk space. Also, if you
need to scale your Terminal Services infrastructure and use load balancing and Session Directory
to distribute your users among more that one terminal server (and you were not taking advantage
of Terminal Services profiles), your users would be maintaining separate profiles on each server.
Implementing Terminal Services profiles addresses both of these issues. Having a central
Terminal Services profile enables the user to receive the same settings regardless of to which
server the Session Directory connects the user. To alleviate the disk space problem, you can
enable a System Policy that deletes cached copies of roaming profiles. This way, after a user logs
off of the terminal server, the disk space is reclaimed once the system copies the profile back to
the central location.

If you do not define a Terminal Services profile path but define a Windows roaming profile path, the
terminal server will use the Windows profile. Also, if the Terminal Services profile is defined but
unavailable, the system will fall back on the Windows profile. This behavior may have undesired
results if you are using application compatibility scripts on your server.

If you use roaming Windows profiles, using Terminal Services profiles can be even more
critical, because if the system does not find a Terminal Services profile path in the user’s
account, it will then look for a Windows profile path and use it instead. In Chapter 5, you will
learn that some applications require application compatibility scripts to function properly on
terminal servers. These scripts often make changes to registry settings under the
HKEY_CURRENT_USER hive to help tune applications for simultaneous users. If these
changes are made to the user’s Windows profile, the user might experience problems the next
time he or she logs on to a workstation.
Geography may also be a factor in separating your profiles. You probably store your users’
Windows profiles on file servers that are close to their workstations, but your terminal servers,
given their low-bandwidth requirements, may be in a central data center. You do not want users
to have to pull their profiles across a slow WAN link.

WS2K3 has two new Group Policy settings that control user profiles. The Allow only local user
profiles setting prevents a specific computer from downloading roaming profiles even if one is
configured on the user account. The Set Path for TS Roaming Profiles setting allows you to configure
a specific file server to be used for roaming profiles for all users logging on to a terminal server.

76
 Chapter 4

Terminal Services Home Directories

You are also able to configure your user accounts to use separate home directories when logging
on to a terminal server. As you will learn in Chapter 5, the system uses the user’s home directory
as its ROOTDRIVE and stores application compatibility files there. Microsoft designed the
ability to use a separate home directory when logging on to a terminal server to keep these files
out of the user’s Windows home directory. The problem is that if your users store their
documents in their Windows home directory, the users will need that same directory available
when logging on to a terminal server. If you define a Terminal Services home path, that path will
be mapped instead of the Windows home path during logon. If you do not define a Terminal
Services home path, the Windows home path is mapped as usual.
Most users will not mind the few files and directories that application compatibility scripts create
and will simply ignore them. If you want, you can modify your application compatibility scripts
to flag these directories as hidden to prevent them from bothering your users.

As with profiles, if you do not define a Terminal Services home path, the system will use the Windows
home path instead. Thus, if you want to use the same home directory for both workstations and
terminal servers, simply leave the Terminal Services home path blank.

Configuring User Properties Through the Active Directory Service Interfaces

Using the GUI tools for user account configuration is fine for managing a small group of users or
making one-off changes, but if you want to configure a large number of accounts, you may find
it easier to use the Active Directory Service Interfaces (ADSI). This feature is a great
improvement over Win2K, for which you had to be a skilled C programmer to access these
attributes.
You access ADSI by using the Windows Script Host (WSH), thus you can choose whether to
write your scripts in Visual Basic Script (VBScript) or Java Script. The examples that I provide
will be in VBScript.
Configuring user properties through ADSI is a three-step process. First, you must open a
connection to the user account, then set the properties, and finally write the changes back to the
user account. To open a connection to the user account, you will use either the WinNT provider
or the Lightweight Directory Access Protocol (LDAP). The WinNT provider is used for Security
Accounts Manager (SAM) accounts—either local accounts on the terminal server or user
accounts in an NT 4.0 domain—and LDAP is used for AD accounts.

Although you can use the scripts in this section to configure both NT 4.0 domain and Win2K AD
accounts, you can only run the scripts on a WS2K3 server; they will not work if run on Win2K or even
Windows XP.

77
 Chapter 4

The syntax for the connection is either

Set objUser = GetObject(“WinNT://<domain name>/<username>,user”
or
Set obUser = Get Object(“LDAP://<distinguished name of user>”)
As you can see, to use LDAP, you must know the distinguished name of the user object (for
example, cn=joe.user,ou=users,dc=example,dc=domain,dc=com), which is difficult if your users
are spread across multiple organizational units (OUs). To make it easier, Microsoft enables the
ability to use the WinNT provider for AD accounts as well. The domain controller will
automatically translate the WinNT call into an LDAP call for you.
Once you have the user account open, you set the parameters that you want to change. The
names of the Terminal Services parameters and the syntax for setting them are provided in
Listing 4.1.
objUser.ConnectClientDrivesAtLogon = [1,0]
objUser.ConnectClientPrintersAtLogon = [1,0]
objUser.DefaultToMainPrinter = [1,0]
objUser.TerminalServicesInitialProgram = [“path to program”]
objUser.TerminalServicesWorkDirectory = [“path to directory”]
objUser.TerminalServicesProfilePath = [“path to directory”]
objUser.TerminalServicesHomeDirectory = [“path to directory”]
objUser.TerminalServicesHomeDrive = [“drive letter:”]
objUser.AllowLogon = [1,0]
objUser.MaxDisconnectionTime = [minutes, 0 for never]
objUser.MaxConnectionTime = [minutes, 0 for never]
objUser.MaxIdleTime = [minutes, 0 for never]
objUser.BrokenConnectionAction = [1,0]
1 = end session, 0 = disconnect the sesion
objUser.ReconnectionAction = [1.,0]
1 = original client only, 0 = any client
objUser.EnableRemoteControl = [0,1,2,3,4]
0 = Disable Remote Control
1 = Enable Notify & Enable Interact
2 = Disable Notify & Enable Interact
3 = Enable Notify & Disable Interact
4 = Disable Notify & Disable Interact

Listing 4.1: Names and syntax for setting Terminal Services parameters.

Finally, you must write the changed attributes back to the user account:
objUser.SetInfo

78
 Chapter 4

Now let’s put it together and set all of the terminal server properties for a single user account.
Listing 4.2 shows an example.
Set objUser = GetObject _
(“LDAP://cn=joe.user,ou=users,dc=example,dc=domain,dc=com”)
‘ or: Set objUser = GetObject(“WinNT://example/joe.user,user”)
objUser.ConnectClientDrivesAtLogon = 1
objUser.ConnectClientPrintersAtLogon = 1
objUser.DefaultToMainPrinter = 1
objUser.TerminalServicesInitialProgram = “C:\windows\notepad.exe”
objUser.TerminalServicesWorkDirectory = “c:\windows
objUser.TerminalServicesProfilePath = _
“\\server\tsprofiles\joe.user”
objUser.TerminalServicesHomeDirectory = _
“\\server\home\joe.user”
objUser.TerminalServicesHomeDrive = “H:”
objUser.AllowLogon = 1
objUser.MaxDisconnectionTime = 15
objUser.MaxConnectionTime = 0
objUser.MaxIdleTime = 180
objUser.BrokenConnectionAction = 0
objUser.ReconnectionAction = 0
objUser.EnableRemoteControl = 1
objUser.SetInfo

Listing 4.2: A script to configure terminal server user properties.

Obviously, if you want to configure a single user account, it would be faster to just use the GUI
tool, but ADSI is a great way to configure properties for multiple users at the same time.

The Microsoft TechNet Script Center (http://www.microsoft.com/technet/scriptcenter) is a great

resource for administrative scripting. With a little scripting know-how, you can modify the example
scripts to meet your unique needs.

Group Policy Overrides of User Settings

WS2K3 includes a new layer of flexibility when configuring user sessions—Group Policy. As
you already know, you can configure session timeouts, client resource settings, and reconnection
options on individual user accounts or on specific servers. With WS2K3 Group Policy, you can
also choose to control all of these options through GPOs.
To provide even greater flexibility, Microsoft allows you to configure these settings as per-user
or per-machine settings within the GPO. Thus, you now have the ability to set all options from a
central location for all servers. You can even apply GPOs to specific security groups so that
Administrators automatically have access to different options than regular users; you won’t need
to go through the trouble of configuring these settings on the individual user accounts. Figure 4.7
shows the Sessions node of the Group Policy Object Editor under Computer (or User)
Configuration, Administrative Templates, Windows Components, Terminal Services.

79
 Chapter 4

Figure 4.7: Configuring session timeouts via GPOs.

All of these options for configuring user and session parameters may seem a little confusing, but
once you start using them, they become very familiar. Also, if you are in an AD environment,
you will probably find that you stop using the user account attributes and the Terminal Services
Configuration tool settings altogether and centralize your settings into GPOs. You should still be
aware of the options available in all the tools, as situations will arise that require a unique
solution.
If you find yourself needing to set options in multiple locations or you are migrating from an
existing Win2K terminal server infrastructure where settings are already configured on your
users or servers, you need to be aware of the priority order of the options:
1. Computer Configuration Group Policy settings
2. User Configuration Group Policy settings
3. Terminal Services configuration tool settings
4. User account settings
Settings with the highest priority will win, so settings in the Computer Configuration will
override User Configuration settings, and so on. As you move to a GPO-based configuration,
you will also need to become familiar with Group Policy processing order, which I will cover in
the next section.

Managing Terminal Servers in an AD Environment

When working in an AD environment, you have the ability to centralize your terminal server
configuration, making it virtually seamless to integrate new servers into your farm. This section
will focus on the tools used to configure and manage terminal servers within AD and introduce
you to AD Group Policy processing.

80
 Chapter 4

Active Directory Users and Computers

Active Directory Users and Computers is the administrative tool used to manage OUs, users,
computers, and groups in AD. Figure 4.8 shows the Active Directory Users and Computers
interface. From this interface, you have the ability to not only manage the directory and the
objects it contains but also quickly access the computer management console for computers in
your domain.

Figure 4.8: The Active Directory Users and Computers interface.

The default configuration for AD organizes the objects into five primary containers:
• Users—The default container for user objects, the User container includes built-in users
such as Administrator and Guest as well as any users that were already in the domain
when upgraded from NT 4.0. This container also holds a number of default domain
global groups such as Domain Admins and Domain Users.
• Computers—The default container for computer objects, the Computers container
includes any workstations and member servers that were already in the domain when you
upgraded from NT 4.0.
• Domain Controllers—The default container for domain controllers.
• Builtin—This container holds the built-in domain local groups that the system uses to
manage native rights such as Server and Account Operators and Administrators.
• ForeignSecurityPrincipals—This container is used by the system to hold referenced users
and computers from other trusted domains.
If you are managing a small to midsized domain, the default containers might meet your needs.
If, however, you need to organize your users and computers for organizational or management
purposes, you can create new OU containers to hold the objects. You can then apply permissions
to the OUs so that groups of administrators have control only over the users and computers in
their own OUs.

81
 Chapter 4

When integrating terminal servers into AD, you will most likely want to create a new OU
specifically for terminal servers. Doing so gives you the ability to apply GPOs to all servers in
the OU without having to worry about adding the servers to security groups in order for them to
receive the policy settings. An exception to this suggestion applies if you are exclusively using
thin clients for your users; in this case, you will not need to create separate GPOs for
workstations and terminal servers.

Group Policy Management Console

With the release of WS2K3, Microsoft also released a new tool for managing GPOs—the Group
Policy Management Console (GPMC). This tool is a vast improvement over the GPO
management capabilities built-in to Active Directory Users and Computers. Using the GPMC,
which Figure 4.9 shows, you can create and edit GPOs; link GPOs to OUs, sites, and domains;
configure security; delegate administration; back up and restore GPOs; create HTML-based
reports to document settings; and even run Resultant Set of Policy scenarios to help you plan
your GPO design.

Figure 4.9: The GPMC interface.

The GPMC is not installed on WS2K3 by default. To download it and read more about its features
and benefits, visit http://www.microsoft.com/windowsserver2003/gpmc/default.mspx.

82
 Chapter 4

Configuring Terminal Servers with GPOs

Once you have AD set up and your terminal servers added to the domain, you are ready to start
designing your GPOs to configure the servers and the user sessions on them. In Chapter 2, I
introduced you to the GPO settings that are used to configure the servers—Session Directory
settings, Terminal Services licensing settings, and so on. In the previous section, I mentioned that
you can use GPOs to configure user and session settings such as timeouts, resource redirection,
and so on. You can also use GPOs to manage the Windows user interface (UI) and to restrict
access to tools and features that a malicious user might take advantage of to destabilize your
server.

UI Settings
The majority of the settings available in a GPO are dedicated to configuring and locking down
the Windows UI. This topic is very volatile, as many users are accustomed to using features that
systems administrators often remove or disable in a Terminal Services environment (such as the
command prompt, Run command, Task Manager, and so on). I recommend reading the
Microsoft article “How to Lock Down a Win2K Terminal Server Session” before you begin this
lockdown process. You can then add or remove restrictions based on your users’ needs and
behavior patterns.

Many of the policy settings are designed to eliminate confusion more than to secure the server. For
example, you will typically remove the Shut Down command from the Start menu even though non-
administrators do not have the rights required to shut down the server.

The following list highlights the policy settings that Microsoft recommends (the settings are
divided into Computer Configuration settings and User Configuration settings):
Computer Configuration settings:
• Do not display last user name in logon screen
• Restrict CD-ROM access to locally logged-on user only
• Restrict floppy access to locally logged-on user only
• Disable Windows Installer—Always
User Configuration settings:
• Folder Redirection: Application Data
• Folder Redirection: Desktop
• Folder Redirection: My Documents
• Folder Redirection: Start Menu
• Remove Map Network Drive and Disconnect Network Drive
• Remove Search button from Windows Explorer
• Disable Windows Explorer’s default context menu
• Hide the Manage item on the Windows Explorer context menu

83
 Chapter 4

• Hide these specified drives in My Computer (enable this setting for A through D)
• Prevent access to drives from My Computer (enable this setting for A through D)
• Hide Hardware Tab
• Prevent Task Run or End
• Disable New Task Creation
• Disable and remove links to Windows Update
• Remove common program groups from Start Menu
• Disable programs on Settings Menu
• Remove Network and Dial-up Connections from Start Menu
• Remove Search menu from Start Menu
• Remove Help menu from Start Menu
• Remove Run menu from Start Menu
• Add Logoff to Start Menu
• Disable and remove the Shut Down command
• Disable changes to Taskbar and Start Menu Settings
• Hide My Network Places icon on desktop
• Prohibit user from changing My Documents path
• Disable Control Panel
• Disable the command prompt (Set Disable scripts to No)
• Disable registry editing tools
• Disable Task Manager
• Disable Lock Computer
Obviously, if you use all the settings that are listed here, you will have a very restrictive and
perhaps unusable environment. For example, Microsoft recommends removing the Map Network
Drive command, but if you are in a distributed environment, your users may require this ability
to access their documents. Nonetheless, this list provides a good starting point.

84
 Chapter 4

I recommend starting with a very restrictive policy, then testing what you can do as you re-
enable certain features. Keep in mind that you should use Group Policy to eliminate confusion
for users and to help protect the system from undesired and inadvertent activity. You should not
rely upon policies alone to secure your server because they leave many loopholes that a
malicious user can exploit. For example, if you use the Prevent access to drives in My Computer
policy as the only method of protecting files on your server, a malicious user could very easily
write a harmful batch file. Instead, you should implement restrictive NTFS permissions to
protect the file system and use the Prevent access to drives in My Computer policy as a way of
preventing a user from mistaking the C drive of the server for the C drive of his or her client
device. The good news is that if you are running the server in Full Security mode, most key areas
of the file system and registry are protected by default.
You also need to be careful to create separate policies for your users and systems administrators.
Obviously, an administrator needs certain features that your users do not. To create separate
policies, create two GPOs, one for users that enables all of the restrictions you want to
implement, and a second for administrators that disables the restrictions on features that you
want to allow them to use. Set the delegation on the user policy to apply to Authenticated Users,
and set the administrators’ policy to apply only to the domain group that contains your
administrative accounts. Finally, place the administrators’ policy above the user policy in the
processing order. Figure 4.10 shows an example of this setup.

Figure 4.10: Using link order to give administrators a less restrictive policy.

85
 Chapter 4

I also recommend keeping your User Configuration in separate policies than your Computer
Configuration. Doing so makes it easier to manage changes and keep the same computer settings
across multiple user policies. If you choose to do so, be sure to disable the User Configuration
settings in the machine policy and vise-versa. Disabling these settings optimizes Group Policy
processing by preventing the processing of GPOs that have no relevant settings enabled.

Restricted Groups
By now, you are well aware that membership in the Remote Desktop Users group is critical to
using a terminal server. For this reason, I recommend managing this group on all of your
terminal servers through Group Policy.
Restricted Groups allows you to manage members of a local machine group through a domain
GPO. This way, when a new terminal server is added to the domain, the server immediately
inherits the proper domain groups into its Remote Desktop Users group. You can manage the
local Administrators group in the same way. Figure 4.11 shows the Restricted Groups node of
the Group Policy Object Editor.

Figure 4.11: Managing groups via GPOs.

Standard Group Policy Processing Order

The order that GPOs are applied is very important. Because you can have multiple policies in
effect for a given user or computer, the Resultant Set of Policy is what will ultimately determine
the settings in effect. To determine the final settings that will be applied to a user, you must look
at all the GPOs that are being applied to that user. GPOs are applied in a fixed order: local, site,
domain, OU. Machine settings and user settings are processed separately, although they can both
come from the same GPOs.

86
 Chapter 4

To understand how GPO processing works, let’s look at a theoretical domain infrastructure and
walk through GPO processing as it happens. Figure 4.12 shows an illustration of an example
domain and its GPOs. For simplicity, I have applied only one GPO at each level. In many
implementations, you will have multiple GPOs at the site, domain, and OU levels. These GPOs
will all have to be processed in order to produce a Resultant Set of Policy.

Figure 4.12: An example domain and its GPOs.

87
 Chapter 4

Let’s start by looking at standard GPO processing by booting up computer1. During the boot
process, security settings are applied for the computer in the following order:
1. Local—The Computer Configuration settings from the cComputer1 Local Policy are
applied.
2. Site—The Computer Configuration settings from the USA Site Policy are applied.
3. Domain—The Computer Configuration settings from the Domain Policy are applied.
4. OU—The Computer Configuration settings from the Workstations OU’s Workstation OU
Policy are applied. The OU policies are determined by the OU that contains the object in
question. In this case, computer1 is in the Workstations OU, so policies linked to that OU
will be processed.
Now that computer1 has a complete configuration, let’s have user Greg log on to computer1 so
that the User Configuration settings are processed:
1. Local—The User Configuration settings from the Computer1 Local Policy are applied.
2. Site—The User Configuration settings from the USA Site Policy are applied.
3. Domain—The User Configuration settings from the Domain Policy are applied.
4. OU—The User Configuration settings from the Users OU’s Users OU Policy are applied.
In standard processing mode, Greg will always receive his User Configuration from this
policy regardless of which OU contains the computer onto which he is logged on.
In standard processing mode, because there are no user objects in the Workstations OU, the User
Configuration of the Workstation OU Policy is never applied. Also, in standard processing mode,
Greg will receive the same resultant set of user policy regardless of to which computer he logs
on. This functionality is advantageous in a large workstation-based domain where Greg may
need to use computers in another department’s OU. However, if you want Greg to receive a more
restrictive policy when logging on to a specific computer (a terminal server, for example), you
will need to implement loopback policy processing.

Loopback Group Policy Processing Order

Loopback processing allows us to take advantage of User Configuration settings from GPOs
linked to the OU that contains the computer that is being accessed. As Figure 4.13 shows, there
are two modes of loopback processing: Replace and Merge. Merge mode instructs the system to
first apply the User Configuration from the Users OU policy (the standard processing order),
then apply the User Configuration from the Computers OU policy. The Resultant Set of Policy is
the combination of both sets of GPOs. Replace mode instructs the system to ignore GPOs from
the Users OU altogether and only apply User Configuration settings from the Computers OU
policy.

88
 Chapter 4

Figure 4.13: Group Policy loopback mode options.

In the previously discussed example domain, we can enable loopback policy processing in merge
mode on the terminal server TS01. In this scenario, the Computer Configuration is applied as
usual, but when Greg connects to TS01, his User Configuration processing is applied in the
following order:
1. Local—The User Configuration from the Computer1 Local Policy is applied.
2. Site—The User Configuration from the USA Site Policy is applied.
3. Domain—The User Configuration from the Domain Policy is applied.
4. OU—The User Configuration from the Users OU’s Users OU Policy is applied.
5. OU Loopback—The User Configuration from the Terminal Servers OU’s TS OU Policy
is applied.
In this mode, Greg could receive his Internet Explorer (IE) proxy server settings from the Users
OU Policy, but have the Shut Down command removed from his Start menu by the Terminal
Servers OU’s TS OU Policy. Merge mode has the advantage of being able to place global
settings in the Users OU Policy and only apply lockdowns in the Terminal Servers OU’s TS OU
Policy. The disadvantage is that in this mode, you need to keep track of user settings in two
GPOs.

89
 Chapter 4

In loopback replace mode, the User Configuration from the Users OU Policy is ignored:
1. Local—The User Configuration from Computer1 Local Policy is applied.
2. Site—The User Configuration from the USA Site Policy is applied.
3. Domain—The User Configuration from the Domain Policy is applied.
4. OU Loopback—The User Configuration from the Terminal Servers OU’s TS OU Policy
is applied.
This mode simplifies GPO processing by placing all settings into the Terminal Servers OU’s TS
OU Policy, but it will force you to keep some settings in this policy in sync with changes made
to the Users OU Policy. For example, if you are configuring IE’s proxy server configuration
through Group Policy, the settings applied in GPOs linked to the Users OU need to match those
in GPOs linked to the Terminal Servers OU (assuming your proxy settings are the same for
workstations and terminal servers). If the proxy server changes, you will need to update both
policies.

Enabling Loopback
Loopback processing is enabled through the Computer Configuration section of the Group Policy
Object Editor (see Figure 4.14). You can enable loopback processing either in the local machine
policy on the terminal server or through any of the GPOs being applied to your terminal servers.

Figure 4.14: The Group Policy Object Editor’s loopback setting.

90
 Chapter 4

Resultant Set of Policy

With a complex domain that employs many Group Policies and combinations of standard and
loopback processing, it becomes very difficult to keep track of the net effect of the GPOs and to
fully predict the result of moving a user or computer from one OU to another. To help with this
challenge, Microsoft provides the Resultant Set of Policy tool (RSOP.MSC).
You can access this tool from a Run command to retrieve the RSOP of the current user and
computer—this information is helpful in identifying the specific GPO that is configuring a
questionable setting—or through the GPMC to assist in testing scenarios of users logging on to
specific computers. The GPMC also provides access to the Group Policy Modeling tool, which
you can use to perform what-if scenarios before making changes to Group Policies or moving
objects.
RSOP.MSC not only shows you the final net effect of all policies applied to a user or computer
but also lets you access a specific setting and see all the policies that configured it along the way.
Figure 4.15 shows the Resultant Set of Policy tool’s interface.

Figure 4.15: The Resultant Set of Policy tool.

Managing User Sessions

If you’re used to a workstation-centric infrastructure, you know that it is a difficult task to
remotely diagnose and correct problems for your users. You probably have used such tools as
Microsoft Systems Management Server (SMS) remote control and Windows XP Remote Support
to work on a user’s computer, and you know how to connect to a network registry to modify
settings for your users.

91
 Chapter 4

In a Terminal Services environment, these tasks are made easier and more straightforward.
Rather than tracking down a specific workstation on a remote node of your network, you and
your users are both logged on to the same computer. And, because you are both utilizing RDP to
transmit KVM data, you can easily tap into the stream to provide assistance. To show you the
various support techniques, I will first introduce you to the support utilities.

Terminal Services Manager

When you launch the Terminal Services Manger administrative tool, you are presented with a list
of all servers that have Terminal Services enabled in the domain. Using this tool, you can easily
see to which servers users are connected, from which client devices they’re accessing the servers,
and which processes and applications they are running in their sessions. Figure 4.16 shows the
Terminal Services Manger interface.

Figure 4.16: The Terminal Services Manager interface.

If you are familiar with the Win2K Terminal Services Manager, you will see some nice
improvements in the version included with WS2K3. First, the new version offers a This
computer node, which gives you quick access to sessions on the server to which you are logged
on. Second, there is a Favorite Servers node, which allows you to quickly access specific
terminal servers that you frequently administer. Finally, for performance, the All Listed Servers
node is not expanded by default, so you no longer have to wait for all terminal servers to be
enumerated before using the tool.

92
 Chapter 4

Once you highlight a specific server, the tool shows you a list of all user sessions on that
terminal server. It also shows you each session’s status using the following categories:
• Active—The user is actively sending keyboard or mouse information to the server.
• Idle—The user has not moved the mouse or entered a keystroke in a given period of time.
• Disconnected—The user has disconnected from the server, but has left the session
running for later reconnection.
If you highlight a user’s session in the left pane, the results pane will show you all processes that
user has running on the server. In this pane, you can end a hung process for the user (see Figure
4.17).

Figure 4.17: Active processes in a user’s session.

The Information tab of the right pane will present you with the user’s client device name and IP
address as well as the version number of the RDP client that he or she is running, the screen
resolution, and the encryption level. This information can assist you in troubleshooting
connectivity problems. If you right-click a user’s session, you are presented with the seven
options that Figure 4.18 shows.

93
 Chapter 4

Figure 4.18: Options available to administrators from the Terminal Services Manager interface.

These commands allow you to interact with the user’s session in several ways:
• Connect—Lets you connect to another session that you have established on a server.
• Disconnect—Disconnects the user from a session, but leaves the session running on the
server.
• Send Message—Sends a pop-up message to the user.
• Remote Control—Allows you to view or interact with the user’s session without
disconnecting the user. The user sees any activity that you perform while remote
controlling, and you can observe the user’s activity as well.
• Reset—Kills the session.
• Status—Shows a status window of network activity between the server and client device.
• Log Off—Forces the user to log off of the session.

The Log Off option will perform a graceful logout and upload the user’s profile to the central profile
directory. However, it will not give the user any opportunity to save work in progress.

Remote Control
When you select Remote Control from the Terminal Services Manager interface, you
temporarily disconnect from your session and are connected to the user’s session. RDP now
sends all video information to both your machine and the user’s client device and receives
keyboard and mouse movements from both of you (if you have configured remote control with
the interact privilege).

94
 Chapter 4

While remote controlling, the user can observe you while you launch applications, change
settings, and so on, and you can observe the user’s activity. One thing to remember is that any
restrictions that you have placed on the user through Group Policy are in effect while remote
controlling, so if you have disabled registry editing in the user’s User Settings GPO, you will not
be able to launch REGEDIT while shadowing the user’s session.

Registry Editing
There are some support issues that may require you to edit a user’s registry. In a workstation
environment, this feature requires you to connect to the remote registry on the user’s
workstation. On a terminal server, you are sharing the same registry with your users. There is
only one HKEY_LOCAL_MACHINE subkey for all users, and each session’s
HKEY_CURRENT_USER subkey can be seen under HKEY_USERS.
Each user’s registry is listed by SID. The quickest way to find a specific user, assuming you
don’t know the user’s SID, is to look in the Volatile Environment subkey for each user. This
subkey contains the APPDATA variable, which will list the username in its path, as Figure 4.19
shows. Any changes you make here are immediately seen by the user.

Figure 4.19: The HKEY_USERS subkey showing user3’s HKEY_CURRENT_USER registry subkey.

95
 Chapter 4

Command-Line Utilities
There are several command-line utilities that you can use to help manage your servers. Most
have direct counterparts in Terminal Services Manager, but the command-line versions can be
useful if you are writing administrative scripts. The following list highlights command-line
utilities:
• CHANGE USER {/Install /Execute}—The CHANGE USER command is used to switch
the server between install and execute mode for application installation.
• CHANGE LOGON {/Enable /Disable}—The CHANGE LOGON command can disable
any new logons from being accepted by the server.
• Query {Process | Session | Termserver | User}—The Query command presents similar
information as the Terminal Services Manager tool presents; this command lists active
processes by session, active sessions, available terminal servers, and current users.
• TSSHUTDN—The TSSHUTDN command is used to shut down or reboot a terminal
server. This command, unlike the Shut Down command from the Start menu, gives your
users a warning that the server is being shut down so that they can save their work. It then
forces a logoff for each session, and finally shuts down the server.

You can shorthand the Query User command to QUSER to get a quick list of active sessions on a
terminal server.

There are several third-party tools that can help you manage and lock down your terminal servers,
plug the loopholes that GPO-based lockdowns leave behind, and manage user profiles and printing.
For example, triCerat Simplify Profiles lets you save and restore, set, and delete end-user registry
settings.

Summary
In this chapter, we explored administrative aspects of Terminal Services, including the multiple
options available for configuring user session parameters and timeouts. In addition, I introduced
you to terminal server profiles and explained when and how to use them. We dove into AD-
based administration, taking you through the often complex topic of Group Policy processing
and how to use loopback processing with terminal servers. Finally, I covered the tools used to
manage and support user sessions on terminal servers.
In Chapter 5, I will dive into the process of installing applications on your terminal servers,
including the user logon process and how it takes advantage of ROOTDRIVE and application
compatibility scripts. We’ll look at how to manage application life cycles and how you can use
IntelliMirror to centrally deploy applications to your server farm.

96
 Chapter 5

Chapter 5: Application Installation and Compatibility

We’ve explored how to enable the Terminal Services role, create and manage a Session
Directory farm, and integrate terminal servers into your AD environment. All of these factors are
vital to a successful Terminal Services infrastructure, but it is the user applications that can make
or break your terminal server deployment.
As Terminal Services evolved, user applications have also evolved. Today, the majority of
applications will install natively on Terminal Services and function in a multi-user environment
without modification. However, there will always be a mission-critical program that is either
legacy or from a vendor that does not follow the Microsoft Windows Logo specifications, so it is
important to become familiar with the various features available in Windows Server 2003 to help
address application compatibility.
This chapter will focus on installing, deploying, and managing applications in a Terminal
Services environment. You’ll learn how to tune applications for simultaneous users, write an
application compatibility script, and use Terminal Services registry flags to handle legacy
applications. I’ll discuss the various administrative modes that you’ll use and how to test an
application for Terminal Services compatibility.

Application Compatibility Mechanisms

Before we dive into the application-installation process, let’s explore the mechanisms available
to assist in making applications that weren’t designed for Terminal Services run on a terminal
server. These mechanisms include Terminal Services logon scripts, application compatibility
scripts, install and execute modes, registry mapping, and INI file mapping.

If an application carries the Designed for Microsoft Windows XP logo, it is usually compatible with
Terminal Services. Microsoft’s certification program assures that the application follows certain
guidelines in its installation process and storage of data and settings, and is compatible with WS2K3’s
features. For more information about the certification programs, go to
http://www.microsoft.com/winlogo/software/windowsxp-sw.mspx.

97
 Chapter 5

Terminal Services Logon Scripts

In addition to any Windows domain logon scripts, Terminal Services uses a sequence of scripts
that run upon user logon to assist you in making any adjustments to your applications so that
they’ll run in a multi-user environment. Figure 5.1 illustrates the user-logon process.

Figure 5.1: The user-logon process.

When you install Terminal Services, the system adds an entry to the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\A
ppsetup registry subkey that will execute the USRLOGON.CMD script that is stored in the
\System32 directory. USRLOGON.CMD is the heart of the Terminal Services logon process,
and it calls a number of additional scripts in its processing. I’ll walk you through this script and
its subscripts and explain a number of Terminal Services concepts along the way.

All the scripts that Microsoft provides are written in shell script, but WS2K3 also has the ability to use
VBScript and JavaScript through the Windows Script Host (WSH).

98
 Chapter 5

USRLOGON.CMD
The first section of the USRLOGON.CMD script calls SETPATHS.CMD. Listing 5.1 shows this
section.
REM USRLOGON.CMD
@Echo Off

Call "%SystemRoot%\Application Compatibility Scripts\SetPaths.Cmd"

If "%_SETPATHS%" == "FAIL" Goto Done

Listing 5.1: The first section of USRLOGON.CMD.

The SETPATHS.CMD subscript checks to make sure that the registry keys for the user’s
application environment are in place. The registry keys for the current user variables can be
found in the
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell
Folders subkey, and the keys for all user variables are in the same subkey under
HKEY_LOCAL_MACHINE. If any of these variables aren’t defined, a warning message is
displayed, and USRLOGON.CMD aborts. Table 5.1 provides the user environment values.
Environment Component Registry Value
All Users: Startup COMMON_STARTUP
All Users: Start Menu COMMON_START_MENU
All Users: Start Menu\Programs COMMON_PROGRAMS
Current User: Start Menu USER_START_MENU
Current User: Startup USER_STARTUP
Current User: Start Menu\Programs USER_PROGRAMS
Current User: My Documents MY_DOCUMENTS
Current User: Templates TEMPLATES
Current User: Application Data APP_DATA

Table 5.1: User environment values.

Next, as Listing 5.2 shows, the script checks for the existence of a script called
USRLOGN1.CMD, and calls it. By default, this script doesn’t exist and would only be used if
you have an application that requires an application compatibility script that does not use a
ROOTDRIVE. This type of application compatibility script would be one that makes changes to
the HKEY_CURRENT_USER hive without referencing any user-specific file locations.
If Not Exist "%SystemRoot%\System32\Usrlogn1.cmd" Goto cont0
Cd /d "%SystemRoot%\Application Compatibility Scripts\Logon"
Call "%SystemRoot%\System32\Usrlogn1.cmd"

:cont0

Listing 5.2: USRLOGON.CMD checks for the existence of and calls USRLOGN1.CMD.

The ROOTDRIVE is a drive letter that the administrator reserves as an absolute path for the user’s
home directory—either network or local—that is the same for all users.

99
 Chapter 5

The next section of the script is designed to create a ROOTDRIVE. The concept of the
ROOTDRIVE was created because most registry keys can’t reference environment variables. For
example, MyApplication.EXE may have a registry value called UserTemplates that defines the
path used to store user-modifiable templates. The best option for this path would be to use
%HOMEDRIVE%%HOMEPATH%\MyTemplates so that each user can be directed to his or her
network home directory (if one exists) or to his or her profile directory on the terminal server.
Because you can’t use environment variables in this registry value, you need an absolute path
that can be resolved for all users. Therefore, on a terminal server, you define a ROOTDRIVE.
USRLOGON.CMD uses a SUBST command to connect the ROOTDRIVE letter directly to the
user’s home directory upon logon. Listing 5.3 shows this section of USRLOGON.CMD.
Cd /d %SystemRoot%\"Application Compatibility Scripts"
Call RootDrv.Cmd
If "A%RootDrive%A" == "AA" End.Cmd

Rem
Rem Map the User's Home Directory to a Drive Letter
Rem

Net Use %RootDrive% /D >NUL: 2>&1

Subst %RootDrive% "%HomeDrive%%HomePath%"
if ERRORLEVEL 1 goto SubstErr
goto AfterSubst
:SubstErr
Subst %RootDrive% /d >NUL: 2>&1
Subst %RootDrive% "%HomeDrive%%HomePath%"
:AfterSubst

Listing 5.3: USRLOGON.CMD connects the ROOTDRIVE letter to the user’s home directory.

The SUBST command is used in Windows to map a drive letter to an absolute path, unlike NET USE,
which maps a drive letter to a universal naming convention (UNC) path. Thus, SUBST W:
C:\WINNT\FONTS would make the W drive an alias for the fonts folder.

How is the ROOTDRIVE letter selected and defined? When an administrator installs an
application compatibility script that references a ROOTDRIVE, the script’s installation script
will automatically ask the administrator to edit a batch file called ROOTDRV2.CMD to define
the letter the administrator wants to reserve, as Figure 5.2 shows. After this reservation is set, the
letter can’t be used for any other mapping on the terminal server.

100
 Chapter 5

Figure 5.2: Setting the ROOTDRIVE letter.

The process that Microsoft uses to connect to the ROOTDRIVE was originally written for
Windows NT 4.0, Terminal Server Edition and doesn’t take advantage of WS2K3’s enhanced
drive-mapping capabilities. To explain this concept, let me walk you through two examples of
how ROOTDRIVE works under NT 4.0, one example using a network home directory, and one
using a local profile directory.

Example 1
Joe User has a home directory defined in his user account that maps H to
\\Server01\Home\Joe.User. Upon logon to the terminal server, H is mapped to \\Server01\Home
(NT 4.0 can only map to the share level). In Joe’s session, the %HOMEDRIVE% variable is now
set to H, and the %HOMEPATH% variable is set to \Joe.User.
Joe uses an application that allows him to create personal templates for his documents, and there
is a registry key that defines the path to store these template files. The registry can’t reference
environment variables, only absolute paths, so we cannot use
%HOMEDRIVE%%HOMEPATH%. If we try to use H for UserTemplates, Joe’s templates will
be created in the root of the home share instead of in his directory.
If the administrator has used ROOTDRV2.CMD to set the ROOTDRIVE variable to W, then
USRLOGON.CMD uses a SUBST command to map W to
%HOMEDRIVE%%HOMESHARE% or H:\Joe.User. Now the path W:\ is an alias for
H:\Joe.User, and the registry can reference W:\ whenever access directly to Joe’s home directory
is needed. In addition, this path can be used for the location of his templates.

101
 Chapter 5

Example 2
Jane Doe doesn’t have a network home directory, so her templates should be stored in her user
profile folder. In Jane’s session, the %HOMEDRIVE% variable resolves to C and
%HOMEPATH% resolves to \WTSRV\Profiles\Jane.Doe. Once again, we can’t use variables in
the registry key, so we don’t have an easy way to reference Jane’s profile directory.
The Administrator has set ROOTDRIVE=W: in the script, so once again USRLOGON.CMD
connects W directly to Jane’s profile directory, and we can use W:\ in the registry.
In Joe’s example, the entire process is used to get around the fact that NT 4.0 can’t map a
network drive to a subdirectory of a share, so
Net Use H: \\Server01\Share\Directory
would connect H to \\Server01\Share. But WS2K3 has the ability to map to the subdirectory
itself, which enables using the home drive as the ROOTDRIVE.
However, without modification USRLOGON.CMD always clears any existing mapping on the
ROOTDRIVE letter before performing the SUBST command, so it doesn’t take advantage of
WS2K3’s enhanced drive-mapping capabilities. Why would you want to use two drive letters to
reference the exact same directory path? You’re better off modifying USRLOGON.CMD to take
advantage of WS2K3’s abilities. You still need to compensate for any users who don’t have
network home directories, but you can easily do so.

If you would like to read Microsoft’s explanation of the ROOTDRIVE, see the Microsoft article “How
and why ROOTDRIVE is used on Windows Terminal Server” at
http://support.microsoft.com/default.aspx?scid=kb;[LN];195950.

Let’s assume that you use network home directories, and you map these on the H drive. If you
set your ROOTDRIVE to H as well, you can avoid mapping two drive letters altogether. Listing
5.4 shows my suggested change to USRLOGON.CMD (the suggested changes are in red).
Cd /d %SystemRoot%\"Application Compatibility Scripts"
Call RootDrv.Cmd

If "A%RootDrive%A" == "AA" goto done

REM If the user has a network Home Directory already mapped

REM on the ROOTDRIVE, we do not need to do anything.

if /I "%rootdrive%" == "%homedrive%" goto NoSubst

:DoSubst
Net Use %RootDrive% /D >NUL: 2>&1
Subst %RootDrive% "%HomeDrive%%HomePath%"
if ERRORLEVEL 1 goto SubstErr
goto AfterSubst
:SubstErr
Subst %RootDrive% /d >NUL: 2>&1
Subst %RootDrive% "%HomeDrive%%HomePath%"
:AfterSubst

:NoSubst

Listing 5.4: Modified USRLOGON.CMD.

102
 Chapter 5

If you aren’t installing any applications that require application compatibility scripts, the ROOTDRIVE
will never be created, and your logon process is greatly simplified.

After the ROOTDRIVE has been established, USRLOGON.CMD calls any application
compatibility scripts that have been installed, then exits, as Listing 5.5 shows.
Rem Invoke each Application Script. Application Scripts are
automatically
Rem added to UsrLogn2.Cmd when the Installation script is run.
Rem

If Not Exist %SystemRoot%\System32\UsrLogn2.Cmd Goto Cont1

Cd Logon
Call %SystemRoot%\System32\UsrLogn2.Cmd

:Cont1

:Done

Listing 5.5: USRLOGON.CMD calls any application compatibility scripts, then exits.

When you install an application compatibility script, a call to it is added to the

USRLOGN2.CMD script so that all application compatibility scripts can be called in turn
without modifying USRLOGON.CMD.

Additional Administrative Scripts

In addition to USRLOGON.CMD and application compatibility scripts, you might want to run
an additional script when your users log on to a terminal server. For example, you might want to
create scripts that map additional network drives or connect to specific printers. If you are in an
AD environment, you can add logon scripts to a User Group Policy Object (GPO).
On a workgroup mode terminal server, you can have the system execute an additional script by
copying the script file to the \System32 directory and modifying the AppSetup value of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
registry subkey. By default, this key lists USRLOGON.CMD, but you can add scripts that are
separated by commas.

For more information about adding scripts, see the Microsoft article “How to Set Up a Logon Script
Only for Terminal Server Users” at http://support.microsoft.com/support/kb/articles/q195461.asp.

Rather than edit the AppSetup registry subkey, you can call additional scripts from within
USRLOGON.CMD. If you aren’t using a ROOTDRIVE, insert the call after :Cont0. If you are using a
ROOTDRIVE, insert the call at the end of the script.

103
 Chapter 5

Application Installation
Now that you understand the process that Terminal Services uses to create an environment that
can assist applications in running for simultaneous users, we can look at how the actual software-
installation process works on a Terminal Services server. In a perfect world, all applications
would follow the guidelines laid out in the Designed for Microsoft Windows XP logo
specification.
This specification instructs programmers to take advantage of several Windows component
services that would make the application natively compatible with WS2K3 and Terminal
Services. The following list quotes and describes the elements of the specification that are of
particular interest to the Terminal Services administrator:
• Do not read from or write to Win.ini, System.ini, Autoexec.bat, or Config.sys on any
Windows operating system based on NT technology—Programs that don’t obey this rule
might store per-user settings in these per-machine configuration files.
• Install using a Windows Installer-based package that passes validation testing and
Ensure that your application supports advertising—The Windows Installer service uses a
process called advertising to ensure that per-user registry keys and files are installed for
each user of a computer and not just the user who installed it.
• Default to My Documents for storage of user-created data—Compliance with this item
ensures that per-user files (documents, macros, templates, and so on) are stored in a per-
user location, not in the program’s directory.
In the real world, however, systems administrators have to deal with many applications—both
current and legacy—that don’t adhere to these guidelines or were written before the specification
was established. To assist in integrating these types of applications, Terminal Services utilizes
registry mapping, INI file mapping, and application compatibility scripts.

Registry Mapping
The Windows registry is divided into two main sections: HKEY_CURRENT_USER and
HKEY_LOCAL_MACHINE. HKEY_LOCAL_MACHINE is used to store global system-
configuration information such as network settings, hardware configuration, and software
settings that are the same for all users. HKEY_CURRENT_USER stores per-user settings such
as cosmetic settings, user preferences, and per-user software configuration. Each user that logs
on to Windows has his or her own HKEY_CURRENT_USER hive.
When you install an application, the HKEY_CURRENT_USER registry keys are created by the
installation program. When other users log on to the computer, they will also need those
HKEY_CURRENT_USER registry keys in order for the application to run as expected. Some
applications use self registration to create these keys. When the application is launched, it looks
for the keys it needs under HKEY_CURRENT_USER. If those keys do not exist, a subroutine is
called within the program to create the keys and set them to default values.
If an application uses the Windows Installer Service, the application can use advertising to create
the HKEY_CURRENT_USER keys. When an advertised application is launched from the start
menu, the Windows Installer Service is invoked and performs a per-user repair on the
application. The repair process creates all required user registry keys and any per-user files that
the application may need.

104
 Chapter 5

Applications that don’t use self-registration or advertising only write HKEY_CURRENT_USER

registry information into the hive belonging to the user that installed the application, so when
another user logs on to Windows, crucial registry settings may be missing from
HKEY_CURRENT_USER. This shortcoming is usually not evident on a workstation, as the
computer is often used by only one person. A terminal server by its very nature, however, is
designed to be shared by multiple users.
To guarantee that all users receive the proper registry settings, Terminal Services uses a process
called registry mapping. When installing an application, the Terminal Services server is placed
into install mode. This mode causes the server to monitor the installation program for any writes
to HKEY_CURRENT_USER. As Figure 5.3 shows, any keys that are written to
HKEY_CURRENT_USER are automatically copied to a special location under
HKEY_LOCAL_MACHINE—they are copied to the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
Server\Install\Software subkey.

Figure 5.3: Registry mapping in install mode for a program called MyApplication.

This mapping of registry keys works only if the installation program uses standard API calls to write to
the registry. Always check the registry after installing an application and before launching it for the
first time to make sure that the mirror has been created. If not, you might need to manually copy the
keys.

105
 Chapter 5

After application installation is complete, the server is put into execute mode. In this mode, if an
application tries to read a registry key from HKEY_CURRENT_USER, and the key isn’t there,
the system will automatically check whether the key exists under the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
Server\Install\Software subkey. If it exists there, the system will copy the key to
HKEY_CURRENT_USER.

INI File Mapping

Before Windows 95, all settings for the system and applications were stored in INI files
(initialization files). Legacy applications will occasionally use these files today. Unlike the
registry, which has separate areas for per-user and per-machine settings, INI files are global, so
changes made by one user would affect everyone on the terminal server. In addition, most
terminal servers are configured so that non-administrative users don’t have adequate rights to
make changes to these system-level files, so applications that reference the files would not run
under the user’s context.
To compensate for this behavior, Terminal Services creates copies of the system INI files and
stores them in each user’s home directory. When an application tries to read from or write to a
system INI file, Terminal Services redirects the call to the user’s copy instead of the original.
While in install mode, any changes that the installer program makes to these INI files are made
to the original copies in the %SYSTEMROOT% directory. Upon logon, the system checks the
user’s copies of the system INI files against the ones in the WINNT directory, and if the user’s
copies of the system INI files are older, the system updates the user’s files. You can disable this
version-checking process by modifying a registry setting, which I’ll discuss later.

Install and Execute Modes

For registry and INI file mapping to work, the system must be in the proper mode for either
application installation or execution. To switch the server into install mode, simply invoke the
Add New Programs Wizard in the Add/Remove Programs Control Panel applet. To switch back
to execute mode, close the wizard. If you try to run a SETUP.EXE program from outside the
Control Panel, the terminal server will correct you by sending the error message that Figure 5.4
shows.

Figure 5.4: Attempting to run an installation program outside the Add/Remove Programs Control Panel
applet results in the presentation of this warning box.

106
 Chapter 5

The terminal server won’t catch all installation programs, so be sure to get in the habit of always using
the Control Panel to install new applications.

Alternatively, you can toggle between install and execute mode from a command line using the
following commands:
CHANGE USER /INSTALL
CHANGE USER /EXECUTE
These commands come in handy if you want to script your application-installation processes.

Application Compatibility Scripts

Many applications don’t take Terminal Services into account and store user-customizable
components on the C drive of the computer. These components can include templates, macros,
and dictionary files. On a workstation, if a user modifies any of these files, the change would
also affect any other user that logs on to the same computer. But on a terminal server, changes
would also affect any other users logged on simultaneously. This behavior can create problems
when these files are in use by one user and can’t be accessed by the instance of the application
running in another user’s session.
Application compatibility scripts compensate for this problem by copying these components to a
location that is unique for each user (usually the home directory), then instructing the application
about where to find the new copies. You can also use application compatibility scripts to grant
user access to certain file and registry locations that are restricted under Terminal Services.
The fact that most application vendors are now complying with the Windows Logo specification
is demonstrated by the reduced the number of application compatibility scripts included with
Windows. You can find the remaining scripts in C:\WINNT\Application Compatibility Scripts
(see Figure 5.5). The scripts are divided into three groups:
• Install—These scripts make system-level changes and add entries to USRLOGON2.CMD
if the application also requires a logon application compatibility script for each user.
• Logon—These scripts are called by USRLOGON2.CMD upon user logon; they copy user
components to the ROOTDRIVE and make HKEY_CURRENT_USER registry changes.
• Uninstall—These scripts remove the calls to the logon scripts from USRLGON2.CMD
when you no longer need the application compatibility script to run.

107
 Chapter 5

Figure 5.5: Application compatibility scripts provided by Microsoft.

As you can see, Microsoft only includes application compatibility scripts for Eudora 4, Visual
Studio 6, and Outlook 98. If you are still using other legacy applications in your environment
(such as Office 97, Project 95, and so on) you might want to copy the application compatibility
scripts folder from a Win2K terminal server to a network share for reference.
When you install an application that requires an application compatibility script, you run the
installation script after installing the application itself. This installation script makes any system
changes that are needed and instructs USRLOGN2.CMD to run the application compatibility
script logon script when users log on.

If you’re installing a non–logo–compliant application that doesn’t have a Microsoft-provided

application compatibility script, see “Installing Undocumented Applications” later in this chapter for
information about how to determine whether you need an application compatibility script and how to
write one.

Examples of Terminal Services Application Installations

Let’s walk through the installation process for three applications: an application that has no
problems running on Terminal Services, an application that comes with a special installation
method for Terminal Services, and an application that requires an application compatibility
script.

108
 Chapter 5

As I mentioned earlier, most current applications are natively compatible with Terminal
Services, so you might find that you can build a successful Terminal Services infrastructure
without ever creating a transform or writing an application compatibility script. However, these
skills are important to learn in case you encounter a mission-critical application that does not run
under Terminal Services out of the box.
The three applications I’ll use for these examples are “old”—Acrobat Reader 5, Netscape
Navigator 4, and Office 2000—but many organizations still run these applications. In addition,
they provide useful examples that you can apply to other applications.

Simple Installation
Adobe Acrobat Reader is a free utility used to open PDF files. This utility has no problems
running on Terminal Services. To install it, you simply use the Add New Programs Wizard in the
Add/Remove Programs Control Panel applet, which Figure 5.6 shows. This wizard places the
server into install mode.

Figure 5.6: The Add New Programs Wizard.

After the installation is complete, click Finish. The server will return to execute mode and
Acrobat Reader is ready for your Terminal Services users. As an exercise, open the registry
editor and compare the settings in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
Server\Install\Software\Adobe to those in HKEY_CURRENT_USER\Software\Adobe to see the
registry mapping in action. When a new user launches Acrobat for the first time, the system will
copy the keys into the user’s HKEY_CURRENT_USER registry hive.

At the time of this writing, Adobe has just released Acrobat Reader 6. This new version is packaged
in MSI format. It also does not require any special steps for terminal server installation.

109
 Chapter 5

Custom Installation
Some software manufacturers take Terminal Services into account when writing their programs
and provide you with instructions about how to install their applications on a terminal server. As
an example, let’s go through the process of installing an application that was designed with
Terminal Services in mind—Microsoft Office 2000. Office 2000 in its raw form has a number of
problems when running on Terminal Services:
• Install on First Use—Because users don’t have the rights to install components on the
terminal server, the Install on First Use option in the Office setup isn’t appropriate.
Instead, we need to set all components to either Run from My Computer or Not
Available.
• User’s name and initials—The Office installer asks for the user’s name and initials during
setup, so all users of the terminal server would end up with the installer’s name. You
need to enable the NOUSERNAME switch to force Office to ask each user for his or her
name on the first use.
• Animation—The frequent screen redraws required by animation are challenging in a
Terminal Services environment, so animation should be avoided where possible. The
Office Assistant is a major culprit and should not be installed.
These problems are addressed by using the Office 2000 Terminal Services transform
(TermSrvr.mst). This transform is a special file that instructs Windows Installer to configure
Office for Terminal Services and to omit certain features of Office 2000 that are problematic.

The Terminal Services transform can be found in the core tool set of the Office resource kit, which
you can download from http://www.microsoft.com/office/ork/2000/appndx/toolbox.htm#orktools.
Microsoft also provides a detailed white paper about installing Office on a terminal server at
http://www.microsoft.com/office/ork/2000/two/30t3_2.htm.

After you have the MST file, you are ready to install Office 2000. Begin by opening the
Add/Remove Programs Control Panel applet, and selecting Add New Programs. Click CD or
Floppy, browse to your Office source files, and select SETUP.EXE. Now you must instruct the
installer to use the transform. To do so, add
TRANSFORMS=path\TermSrvr.mst
to the command, as Figure 5.7 shows.

110
 Chapter 5

Figure 5.7: Installing Office 2000 with the Terminal Services transform.

After the installation is complete, click Finish to put the Terminal Services server back into
execute mode. I recommend installing the latest service release for Office, as there are some
bugs that affect Terminal Services users that have been corrected.
You should now take the time to set up some custom settings for your users. You can do so by
using the Office Profile Wizard or the Office 2000 ADM files in conjunction with the local
policy editor or a domain Group Policy. If you want to use the Office Profile Wizard, follow the
documentation that Microsoft provides. If you’re in an AD domain and are using Group Policy to
manage your user settings, see Chapter 4.
To use local policy, find the ADM files that were included in the resource kit (which you
downloaded to get the MST file), then launch the local policy editor, which Figure 5.8 shows, by
typing
GPEDIT.MSC
from the Start menu’s Run text box.

111
 Chapter 5

Figure 5.8: The Group Policy editor.

Next, right-click Administrative Templates, and select Add/Remove Templates. Add the ADM
files for the programs that you have installed. Table 5.2 lists the ADM files associated with
Office programs.
Office Program ADM File
General Office Settings OFFICE9.ADM
Word 2000 WORD9.ADM
Excel 2000 EXCEL9.ADM
PowerPoint 2000 PPOINT9.ADM
Outlook 2000 OUTLK.ADM
FrontPage 2000 FRONTPG4.ADM
Access 2000 ACCESS9.ADM
Publisher 2000 PUB9.ADM

Table 5.2: Office ADM files for local or Group Policy.

After you have added the ADM files, you have access to a large number of settings that you can
preconfigure or disable for your users, as Figure 5.9 shows.

112
 Chapter 5

Figure 5.9: Settings available with the Office ADM file.

You should go through these settings and customize Office for your users. You’ll want to disable
any features that use sound or animation. Remove the Detect and Repair command from all the
Office products. You might also want to disable the Check Spelling as you Type and Check
Grammar as you Type options in each program, as these features are very processor intensive,
especially when you have multiple users.
You should be aware that if you use the Local Machine Policy to configure your settings, the
settings apply to all users, including administrators. But, for settings within Office programs, this
behavior is usually not a problem.
With the release of the Windows XP generation of Office programs, Microsoft has begun to
include the required modifications for terminal servers in the native MSI package. When you
install Office XP on a terminal server, Windows Installer recognizes that you are on a terminal
server and makes the changes to the setup parameters automatically. A transform is no longer
needed.

Even with these new enhancements in Office XP setup, there are still some post-installation changes
you will want to make using the Office XP ADM files. For details, see
http://www.microsoft.com/office/ork/xp/one/deph02.htm.

113
 Chapter 5

Application Compatibility Script Installation

Some applications require post-installation modifications or on-the-fly changes upon user logon.
These changes are made by using an application compatibility script. You have already seen the
list of application compatibility scripts that Microsoft provides for Terminal Services, and I’ll
use one of these applications as an example—Netscape Communicator 4.5.
We begin, as with any other application, with the Add New Programs Wizard. Install Netscape
as you normally would, then click Finish to close the wizard. Now we must install the
application compatibility script. Before we do so, let’s examine why Navigator 4.5 requires an
application compatibility script:
• User Profiles—By default, Navigator 4.x stores user profiles (favorites, settings, history)
in the program’s directory. Users on a terminal server don’t have write access to the
Program Files directory, so we need to direct Netscape to store profiles in the user’s
home directory instead of on the terminal server, and automate the profile setup for each
user upon logon.
• User Profile Manager—Navigator has a profile-manager program that, in its native state,
allows users to modify or delete other profiles on the terminal server. We need to restrict
access to this utility.
• Quick Launch Toolbar—Users will want an icon for Netscape in their Quick Launch
toolbar. The application compatibility script can create this icon for them upon logon.
To run the script, browse to C:\WINNT\Appliation Compatibility Scripts\Install and run
NETCOM40.CMD. The script performs the following actions:
• Checks whether you’ve defined your ROOTDRIVE letter and asks you to do so if you
haven’t.
• Copies the Quick Launch icon from your profile to the Netscape program directory as a
template for future users.
• Copies the Netscape profile directory that the setup program created for you to be a
template for other users.
• Applies restrictive permissions to the Netscape profile-manager utility to prevent non-
administrators from running it.
• Modifies the application compatibility script logon script for Netscape to reflect the
ROOTDRIVE letter that you have chosen.
• Adds a call to the application compatibility script logon script for Netscape to
USRLOGN2.CMD so that the application compatibility script will run upon logon for all
users.

114
 Chapter 5

When a user logs on, COM40USR.CMD (the application logon script for Netscape), is called
and performs the following actions:
• Copies the template User Profile to the user’s ROOTDRIVE if it doesn’t already exist.
• Modifies the Netscape section of HKEY_CURRENT_USER to point Netscape to the
profile in the ROOTDRIVE.
• Creates the Quick Launch icon if it doesn’t exist.
Netscape is now ready for simultaneous users.

Installing Undocumented Applications

You can now install any application that is either natively compatible with Terminal Services or
comes with Terminal Services-compatibility instructions. But what do you do when you
encounter an application that has no Terminal Services documentation? You need to learn how to
determine whether any post-installation changes are necessary or an application compatibility
script needs to be written. This skill is important but is less frequently used as more and more
applications follow Microsoft’s certification specifications.
Begin by checking the application publisher’s Web site and search the online support area for
references to “terminal server” or “Citrix” (even though we’re installing the application on a
Terminal Services server without MetaFrame, you might find useful information indexed under
Citrix, as it has been the leader in terminal services for so long). If you can find nothing there,
turn to online discussion forums and query for the name of the application AND “terminal
server” OR “Citrix.” Keep in mind that anyone can post to most forums, so you need to be very
careful with any advice you find.

The following Web sites are useful in searching for help with installing an undocumented application:
http://www.thethin.net
http://www.thinplanet.com

After collecting any information you find about your application, install the application on a test
server. Your test server should have the same configuration as your production boxes—service
packs, hotfixes, logon scripts, and so on.

Never install an untested application on a production server!

As with any other application, install through the Add New Programs Wizard. If the application
requires a post-installation reboot, do that as well. Before launching the application for the first
time, examine the registry. Begin in the HKEY_LOCAL_MACHINE\SOFTWARE key and find
the subkey for the application. Look through the values and pay careful attention to any data that
contains an absolute path. Values such as InstallPath or ApplicationSource are fine, as these
would be the same for all users, but values that reference user settings, such as UserDictionary or
UserHome, may be problematic. Make notes of these keys.

115
 Chapter 5

Next, look at the HKEY_CURRENT_USER\Software key to determine whether the application

configured any registry keys. If so, look for the same types of values here and make notes of any
that you find. Also check whether the keys were mirrored in the Terminal Server section of the
HKEY_LOCAL_MACHINE hive. If not, you should create a .REG file of the application’s
HKEY_CURRENT_USER\Software key by selecting regedit’s Export Registry File option from
the Registry menu. You will need this file later if you need to manually mirror the keys.

Be sure to export the application’s HKEY_CURRENT_USER\Software key before you launch the
application for the first time. You don’t want to capture any current user settings that are generated at
first launch.

Now launch the application under the same account that was used to install it. Go through the
application’s functions and look for problems—error messages, incorrect behaviors, and so on.
Then log on to the terminal server with a test account. This account should not be an
administrator on the terminal server and should be configured like your regular users. Launch the
application and run through the same tests. If no errors are found, close the application, and
check the registry for this user.
Confirm that the application’s HKEY_CURRENT_USER keys were properly copied from the
Terminal Server key in HKEY_LOCAL_MACHINE or were automatically generated by the
application. If there are keys missing when you compare them to those under the installer
account, you should mirror the keys yourself. To do so:
1. Open in Notepad the .REG file that you previously created, and select Replace from
the Edit menu to change all occurrences of HKEY_CURRENT_USER\Software to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Terminal Server\Install\Software.
2. Import the .REG file back into the registry.
Now delete the profile (both local and roaming) of your test account, and log on. Launch the
application and confirm that the mirrored registry keys were copied. If they were, and you
determine that you need to make any registry changes for your users, you can make them under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
Server\Install\Software and the new settings will be copied when your users launch the
application for the first time.
Now look at your notes for any registry keys that you found that point to user-specific files. If
you found any references to user files stored on the local drives of the terminal server, you
should try copying these files to a subdirectory of your ROOTDRIVE, then modifying the
registry key to point to the new location. If the key is in HKEY_LOCAL_MACHINE, just
modify it there. If the key is in HKEY_CURRENT_USER, change it there AND in the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
Server\Install\Software subkey. Be sure to document any changes you make so that you can
make them again when you install the application on your production terminal server. Launch
the application and confirm that it doesn’t have a problem with the new location.
This process is mostly trial and error and is different for each application you install. Take heart
in the fact that you need to go through this process only for applications that aren’t certified for
Windows.

116
 Chapter 5

A Real World Example

Let’s walk through an example of an application that needs to be modified for terminal server
use. Let’s assume that WorkGroup is a problem-tracking system that your company uses to
manage projects. It references a SQL database to store project descriptions, timelines, and team
members’ notes. You want to install WorkGroup on your terminal server so that you can have
your users run it from within a Web page (using the Remote Desktop Web Connection client)
instead of installing it locally on every workstation.
The publisher’s Web site makes no reference to terminal server, and when you call the
company’s technical support number, you’re informed that the vendor “Does not support the
application on Terminal Services.” You also check the usual newsgroups, but as this application
is uncommon, you find no mention of it. You’ll need to test the application yourself to determine
whether it’s compatible with Terminal Services and requires an application compatibility script.
Begin by using the Add New Programs Wizard to run SETUP.EXE for WorkGroup. The
installer doesn’t require a reboot, so immediately go to regedit, and examine
HKEY_LOCAL_MACHINE\SOFTWARE for absolute paths under WorkGroup’s key, as
Figure 5.10 illustrates.

Figure 5.10: HKEY_LOCAL_MACHINE key for the WorkGroup application.

Under the Paths key, you find the location of the SQL database, which will be the same for all
users, so this key shouldn’t be a problem for Terminal Services. Under SpellCheck, however,
you find a value that may pose a problem—DictionaryPath. After closer inspection, this value
looks like it’s the base lexicon file that all users will share, not a per-user file. Make a note of this
key, just in case.
Next, look to HKEY_CURRENT_USER\Software for similar values. Here you find another
SpellCheck key, and it contains the location for the user’s custom dictionary file—C:\Program
Files\Workgroup, as Figure 5.11 shows.

117
 Chapter 5

Figure 5.11: Example of a per-user file stored in a common location.

This key raises a red flag for Terminal Services. Each user should have his or her own
USER.LEX file for WorkGroup, but this file, by default, is stored on the terminal server, not in
each user’s home directory. Luckily, WorkGroup gives you a modifiable registry key for the
file’s location, so the problem should be easy to fix. You make a note that this problem will have
to be addressed.
Next, you determine whether registry mapping has worked by comparing this
HKEY_CURRENT_USER key to the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
Server key, as Figure 5.12 shows.

Figure 5.12: The location for mirrored registry keys.

As you see in Figure 5.12, registry mapping hasn’t occurred, so you might need to perform the
registry mapping yourself (if you determine that you need to preconfigure
HKEY_CURRENT_USER settings for your users). In case you do, you should create a .REG
file from HKEY_CURRENT_USER\Software\SoftwareCo\WorkGroup now.

118
 Chapter 5

You now launch WorkGroup to determine whether it will run under the installer account. Let’s
assume that you don’t encounter any problems. You’re able to connect to the database, read and
enter data, and perform queries. So now you do the same test under a non-administrative test
account. Once again, the application launches without a problem, but when you try to add a word
to the custom dictionary, the program crashes—the test account doesn’t have write access to the
USER.LEX file stored on the C drive. You need to attempt to compensate for this shortcoming.
First, test whether WorkGroup will let you move the USER.LEX file to a new location. Logged
on as the installer account once again, you copy the file from C:\Program Files\WorkGroup to
H:\WorkGroup, and change the UserDicPath value under HKEY_CURRENT_USER to
H:\WorkGroup. Now launch WorkGroup and add a new entry to the dictionary. By checking file
timestamps, you can confirm that the word was added to the copy on the H drive, so the change
was successful.
To replicate this change to all users on the terminal server, you’ll need to perform two tasks:
• Change the UserDicPath value for the each user.
• Copy the USER.LEX file to the ROOTDRIVE when each user logs on.
You should be able to make the registry change through registry mapping, but you’ve already
discovered that you’ll have to set up this mapping manually. The file copy will require an
application compatibility script. Let’s take each of these tasks in turn.
To set up registry mapping, edit the .REG file you created from HKEY_CURRENT_USER by
right-clicking the file and selecting Edit. Use the Replace command to change all instances of
HKEY_CURRENT_USER\Software to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
Server\Install\Software.
Also, find the UserDicPath value and change its data to H:\WorkGroup in the .REG file. Save
the updated file to C:\WINNT\Application Compatibility Scripts\Install. You’ll confirm that this
new setting gets copied from HKEY_LOCAL_MACHINE to HKEY_CURRENT_USER for the
test account after we take care of the application compatibility script.
To accomplish the file copy, you need to write a pair of application compatibility scripts—one
installation script and one logon script. For this application, both scripts will be very simple. To
copy the file to the proper location, you’ll need to have a ROOTDRIVE defined, so the
installation script should confirm that this drive has been established. Next, the installation script
should import the .REG file that you created to set up registry mapping and add a call to the
application compatibility script logon script to USRLOGN2.CMD. Figure 5.13 shows an
example application compatibility script installation script.

Manually importing the .REG file and editing USRLOGN2.CMD yourself would be easy, but by using
an application compatibility script installation script, we make the process easily repeatable when we
install the application on the production terminal server. Make sure that you maintain a central
location for all application compatibility scripts that you create so that you can replicate them onto
new servers when you build them or install new applications.

119
 Chapter 5

Figure 5.13: An example application compatibility script installation script.

Before running the installation script, you need to write the application compatibility script logon
script that will perform the file copy for each user. This script will be called every time a user
logs on, but it should copy the file only if the file doesn’t already exist in the user’s
ROOTDRIVE, so be sure to include logic in your scripts to check this. This script file should be
saved in C:\WINNT\Applicaiton Compatibility Scripts\Logon. Figure 5.14 shows an example
application compatibility script logon script.

Figure 5.14: An example application compatibility script logon script.

Now that all the pieces are in place, execute the application compatibility script installation script
for WorkGroup. You should now test the application compatibility script process by logging on
as your test account. Be sure to delete this account’s profile—both roaming and local—before
logging on so that you have a clean testing environment.

120
 Chapter 5

After logging on, first look in the test account’s home directory to confirm that the USER.LEX
file was created in the WorkGroup subdirectory. If not, go back and confirm that your
application compatibility script installation script correctly added the call command to
USRLOGN2.CMD, then debug your application compatibility script logon script.
Next, launch WorkGroup, and confirm that all registry keys, especially the modified
UserDicPath value, were copied into HKEY_CURRENT_USER for the test account. Add a
word to the custom dictionary for the test account, and confirm that the word was added to the
copy in the home directory.
After all of this process has been tested, you should also perform a test on WorkGroup by
running it under several test accounts simultaneously. If you’re satisfied with its performance,
you’re ready to repeat the installation on your production server.

Terminal Services Compatibility Flags

When you install an application, Terminal Services creates a compatibility flag registry key,
which Figure 5.15 shows, that instructs Terminal Services about which type of program the
application is (MS-DOS, 16-bit, 32-bit). If you’re installing a legacy application that will not run
on Terminal Services, you can change this flag so that Terminal Services makes adjustments
when the application is launched.

Figure 5.15: The compatibility flags registry values.

The flags that can be set here affect memory allocation and registry and INI file mapping. They
can also be used to instruct Terminal Services to return the %USERNAME% value whenever the
application queries the %COMPUTERNAME%. This feature can come in handy if the
application uses the hostname of the computer as a unique identifier. Typically, only older legacy
applications require adjustments.

If you have a program that will not run under Terminal Services, read the Microsoft article “Terminal
Server Registry Settings for Applications” at
http://support.microsoft.com/default.aspx?scid=kb;[LN];186499.

121
 Chapter 5

Installing Applications Through Group Policy

If you are managing a large terminal server farm or need the ability to expand your farm quickly,
you will want to use an automated software installation technology. In an AD environment you
can use Group Policy to assign applications to your servers. When the server boots, the machine
policies are processed and any applications that are assigned will be installed.
To use Group Policy to install applications, your applications must be in MSI format. Group
Policy also supports a script format called ZAP, which can trigger a non-MSI installer. However,
the use of this format is not recommended with terminal servers because such applications do not
support advertising, so your users may not receive necessary HKEY_CURRENT_USER registry
keys.

You can repackage software into the MSI format by using a third-party utility such as Wise for
Windows Installer. Be sure to thoroughly test the application on Terminal Services before and after
repackaging to determine whether any modifications need to be made for terminal server
compatibility.

The basic steps required for Group Policy-based software installation are:
1. Create a network share to store your MSI packages.
2. Create Administrative Installations of your MSI packages and place them on the share.
3. Add the packages to a GPO that applies to the terminal server computers in AD.
4. Modify the permissions on the packages in the GPO if you want to filter which terminal
servers receive each package.
5. Reboot the terminal servers.

Create a Share
To assign or publish an application via Group Policy, you need a central location to reference for
the application source files. The path to this location must be resolvable and accessible by all
computers to which the policy applies. The easiest way to accomplish this is to create a share on
a file server and copy the source files to it.

Make sure that the machine accounts of your terminal servers have read and execute rights on the
share. The Authenticated Users and Everyone groups both include machine accounts.

Create Administrative Installations

MSI packages typically come with all of the files needed for the application compressed into
CAB files. To optimize the installation of the software, uncompress the files in advance by
creating an Administrative Installation.
To create an Administrative Installation, execute the Windows Installer Service with a “/a”
switch, and specify the path and name of the MSI package you want to uncompress:
msiexec /a d:\proplus.msi

122
 Chapter 5

A wizard, like the that Figure 5.16 shows, should appear asking you for the destination directory
for the Administrative Installation. If the application requires a license key for installation, the
wizard will prompt you for this as well. The key is then encrypted into the Administrative
Installation so that installs performed from that source will not be prompted for the key.

Figure 5.16: An Administrative Installation wizard.

Once the Administrative Installation is complete, copy the new source files to your share.

Add the Packages to a GPO

In Chapter 4, we created an OU for terminal servers and linked three GPOs to that OU. One of
the GPOs was the Terminal Server Machine Policy. This GPO contained the machine
configuration for your terminal servers, so it already is configured to apply to your terminal
servers. You can add your software packages to this GPO, and they will be installed on all
computers in the TerminalServers OU.
To add a package to a GPO, edit the policy and expand Computer Configuration, Software
Settings. Right-click Software installation, and select New, Package (see Figure 5.17).

123
 Chapter 5

Figure 5.17: Adding a software package to a GPO.

You will be prompted for the MSI package that you want to add. Navigate to your share and
select the MSI file that you want to install. You will then be asked whether you want to assign
the package or open the Advanced Settings interface. In most cases, you can select Assign and
accept all of the default options. If, however, you need to specify a transform to be applied
during the installation, select Advanced.

A transform (MST file) specifies options or makes changes to the default settings of a Windows
Installer package (MSI file). You can create transforms by using the Microsoft Office Custom
Installation Wizard or with a third-party utility.

Filtering Applications
You can use a single GPO that applies to all of your terminal servers and still filter which
applications are installed on each server by using security filters on the packages in the GPO.
Figure 5.18 shows a GPO that contains three software packages—Adobe Acrobat Reader 6,
Office XP, and the Microsoft Group Policy Management Console.

124
 Chapter 5

Figure 5.18: A Group Policy that has three software packages applied.

Let’s assume that you want to install Acrobat Reader and Office XP on all terminal servers to
which the GPO applies, but you only want to install the console on the terminal servers that
administrators use. By default, the packages will inherit security settings from the GPO, so any
computers that have read permission on the GPO will also have read permission on the package,
and will therefore install the software during boot up.
You can change the permissions on the package and limit the ability to read it to only a specific
group of computers. By doing so, all computers in the OU will process the policy, but only those
with read permission on the package will install it. Figure 5.19 shows the default permissions on
a package and the permissions after they have been modified so that only the Admin Terminal
Servers group can read it.

125
 Chapter 5

Figure 5.19: Filtering security on a software package.

For this security filter to work, you will need to create a Domain Security group—Admin
Terminal Servers, for example—and place the servers you want to receive the console into that
group.

To modify the permissions of a package, you have to break inheritance on the GPO’s permissions. To
do so, click Advanced, and clear the Allow inheritable permissions check box. You can then choose
to copy the existing permissions and use them as a starting point for your modifications.

Reboot the Terminal Servers

A major limitation of Group Policy-based software installation is that it only is processed during
boot up. If you add a new package, you must reboot your servers to install it. Using GPO-based
installation is still useful in that new servers that are built and placed in the Terminal Servers OU
will automatically install the required packages, saving you the time and effort of installing them
on every new server.

You can also use GPOs to upgrade and uninstall software. Check out Darren MarElia’s The Definitive
Guide to Windows 2000 Group Policy (Realtimepublishers.com) available from a link at
http://www.realtimepublishers.com for an in-depth look at Group Policy-based software management.

There are several software management systems available that can install software on a
scheduled basis without requiring a reboot. Microsoft Systems Management Server and Citrix
MetaFrame XPe both have the ability to schedule installations and manage the software outside
the Group Policy process.

126
 Chapter 5

Deploying Applications to End Users

If you’re using Terminal Services as a desktop replacement, deploying a new application to your
users is as simple as adding an icon for the program to the All Users Start menu on your terminal
server. If, however, you want to deploy a single application in an application service provider
(ASP) model, your deployment method will be determined by the type of terminal server client
you’re using.
If your users access Terminal Services applications through the local Remote Desktop
Connection client, you’ll need to create an RDP file that contains the server name and initial
application path for the new application, then distribute it to your users.
If you want to deploy an application through the Remote Desktop Web Connection Client so that
your users will go to a URL to launch the program, you should reference the documentation that
Microsoft provides with the client to customize the Web page that hosts the application. The
Web Connection Client is very powerful and customizable, so with a little HTML and ActiveX
scripting, you can create a very robust portal for your ASP-based applications.

Summary
In this chapter, we explored the mechanisms that Terminal Services use to host applications for
simultaneous users, even when the application is not designed to handle them. I examined the
Terminal Services logon script process and administrative modes, and explained application
compatibility scripts. We defined the ROOTDRIVE and how this concept can be modified to
take advantage of network home directories and WS2K3’s enhanced drive-mapping capabilities.
This information enables you to install applications on your terminal server, test them for multi-
user compatibility, and write an application compatibility script if necessary.
Finally, we walked through the process of using Group Policy to automatically install software
on your servers. This functionality will help streamline the process of building new servers,
allowing you to scale your terminal server farm quickly and easily.
In Chapter 6, we’ll explore a very hot topic—patch management. With the number of viruses and
worms over the past few years, it is critical that you keep your servers up to date with the latest
security updates and software patches. I’ll be covering some options that make this process easy
and automatic.

127
 Chapter 6

Chapter 6: Managing Security and Virus Protection

Blaster, Love Bug, Nimda, Melissa—computer viruses and worms are a fact of life these days,
so Windows infrastructure design must take them into account. Virus scanning software,
firewalls, and patch management should be a part of even the smallest environments. If users
will be accessing email or browsing the Internet from terminal servers, you will need to be
vigilant in keeping your servers safe and virus free. Luckily, the restrictive permissions on a
terminal server make it difficult for users to introduce viruses to the system; nonetheless, you
should be prepared.
In this chapter, we will explore available options for keeping servers secure and up to date,
including Microsoft Automatic Updates and Software Update Services, as well as best practices
for implementing these options in your environment. In addition, I will highlight considerations
for installing virus scanning software on terminal servers.

Viruses, Worms, and Trojan Horses…Oh My!

There are many types of malicious code (malware) from which you must protect your systems.
Although malware is often referred to as viruses, there are distinct differences between viruses,
worms, and Trojan horses.
A virus is a small program that is written to alter—without the knowledge of the user—the way
that a computer operates. To be called a virus, the program must be executable code—either in
the form of a standalone program or as a macro contained in another file—and must be able to
copy itself so that it can continue to execute once the initial program or macro is terminated.
Examples of viruses include:
• Boot sector viruses, such as Michelangelo and Disk Killer, which install themselves in
the boot sector of your hard disk so that they begin execution before the OS
• Macro viruses, such as Melissa and Nice Day, which are contained inside macros in
Office documents. These viruses execute when the document is opened, and attempt to
infect other Office documents or the normal template so that all new documents created
on the computer are infected.
A worm is a program that takes advantage of poor security design or security flaws in the OS.
Worms are able to spread from one computer to another without a host file, although some
spread by copying an infected file from one computer to another. Blaster is an example of a
worm that takes advantage of a security flaw in the Windows remote procedure call (RPC),
allowing it to remotely execute code on other computers on the network to replicate itself.
A Trojan horse is a program that is contained inside of another, seemingly desirable, application.
When you execute the host program (for example, a screen saver, an e-greeting card, or a
shareware application), the Trojan horse is installed on your system. Trojan horses can act as
spyware, sending private information to a third party, and are used in distributed Denial of
Service (DoS) attacks. The main difference between a virus and a Trojan horse is that a Trojan
horse does not self-replicate—it must be manually executed to infect your system.

128
 Chapter 6

A DoS attack makes a large number of requests against a specific server or URL, keeping the server
busy so that it cannot service legitimate requests. A distributed DoS attack uses a virus, worm, or
Trojan horse to enslave multiple computers across the Internet and directs them all to attack the
server simultaneously.

You must protect your terminal servers from all three types of malware. You can do so through a
combination of file system permissions, Group Policy settings, virus protection software, and
security patches distributed by Microsoft.
If you accept the default file system permissions and keep your users restricted to the Users
group (not elevating them to Power Users), your system is protected from most viruses and
Trojan horses that attempt to install themselves into system files or the system root or program
files directories. In addition, you can use Group Policy to enforce addition restrictions—limiting
which processes and applications a user can execute, preventing users from saving files to the C
drive of the server, and so on—to further protect your systems.

For more information about using Group Policy to secure your terminal server, see Chapter 4.

Even with the enhanced security that WS2K3 implements on the file system and the additional
restrictions you can apply through Group Policy, it is a good practice to install and maintain
virus protection software and a patch-management system—virus authors are always coming up
with new ways to harm your system.

Internet Explorer Enhanced Security Configuration

Internet Explorer Enhanced Security Configuration is a new option included with WS2K3. When
installed, it changes the default security settings in Internet Explorer to limit the exposure to
potentially damaging code found in Web content and application scripts.
Internet Explorer Enhanced Security Configuration is installed by default for all user groups on
WS2K3 unless you are adding the Terminal Services role—the configuration of Internet
Explorer Enhanced Security Configuration on a terminal server depends on the method used to
install the OS. Table 6.1 shows the configuration of Internet Explorer Enhanced Security
Configuration under different installation methods.
Enhanced Security Configuration is Applied
Type of Installation
Administrators Power Users Limited Users Restricted Users
Upgrading the OS Yes Yes No No
Unattended installation of the OS Yes Yes No No
Manual installation of Terminal Services Yes Yes Prompt Prompt

Table 6.1: Configuration of Internet Explorer Enhanced Security Configuration on a terminal server.

129
 Chapter 6

When installing the Terminal Services role manually, the Configure Your Server Wizard will
prompt you to disable Internet Explorer Enhanced Security Configuration for the Limited Users
and Restricted Users groups. Doing so improves the browsing experience for these users and
relies on the native security of the file system and OS to prevent these users from running or
installing malicious code.

Regardless of whether Internet Explorer Enhanced Security Configuration is enabled, the Limited
Users and Restricted Users groups are prevented from installing ActiveX controls on a terminal
server. An administrator must manually install all approved controls on the server. Methods for doing
so are described later in this section.

To manually enable or disable Internet Explorer Enhanced Security Configuration, use the
Add/Remove Programs Control Panel applet, as Figure 6.1 shows.

Figure 6.1: Enabling or disabling the Internet Explorer Enhanced Security Configuration through the
Add/Remove Windows Components tool.

If you want to enable Internet Explorer Enhanced Security Configuration for all users, simply
select the associated check box. To specify to which groups Internet Explorer Enhanced Security
Configuration is applied, click Details. In the resulting window, which Figure 6.2 shows, you can
apply the enhanced security to administrators and all other groups individually. On a terminal
server, a best practice is to enable it for administrators and leave it disabled for other user groups.

130
 Chapter 6

Figure 6.2: Applying Internet Explorer Enhanced Security Configuration to specific user groups.

Changes Made by Internet Explorer Enhanced Security Configuration

Internet Explorer Enhanced Security Configuration changes the default zone settings for IE and
adjusts several IE advanced settings to further increase protection from malicious code. Table 6.2
shows the changes made to the security levels of each zone.
Zone Default Level Internet Explorer Enhanced
Security Configuration Level
Internet Zone Medium High
Local Intranet Zone Medium Low Medium Low
Trusted Sites Zone Low Medium
Restricted Sites Zone High High

Table 6.2: Zone security level changes made by Internet Explorer Enhanced Security Configuration.

In addition to the security level changes, Internet Explorer Enhanced Security Configuration
changes the default zone for all intranet Web sites. By default, all intranet sites (determined by
your DNS suffix) are in the Local Intranet Zone. With Internet Explorer Enhanced Security
Configuration enabled, intranet sites are placed in the Internet Zone and are treated with High
security until you add them to the Local Intranet Zone manually. The only sites in the Local
Intranet Zone under Internet Explorer Enhanced Security Configuration are local machine sites
(http://localhost, https://localhost, hcp://system). Local machine sites must be in the Local
Intranet Zone for many of the Help and Administrative Tools to work properly. Internet Explorer
Enhanced Security Configuration also changes advanced options, as Table 6.3 shows.

131
 Chapter 6

Feature Entry
Display enhanced security
Browsing
configuration dialog box
Browsing Enable Browser Extensions
Enable Install On Demand
Browsing
(Internet Explorer)
Enable Install On Demand
Browsing
(Other)
Microsoft JIT compiler for virtual machine
VM enabled (requires restart)
Don't display online content in
Multimedia
the media bar
Multimedia Play sounds in Web pages
Multimedia Play animations in Web pages Off
Multimedia Play videos in Web pages
Check for server certificate
Security
revocation (requires restart)
Check for signatures on
Security
downloaded programs
Do not save encrypted pages to
Security
disk
Empty Temporary Internet Files
Security
folder when browser is closed
New
Result
Setting
Displays a dialog box to notify you when an
On Internet site tries to use scripting or ActiveX
controls.
Disables features you installed for use with IE that
Off might have been created by companies other than
Microsoft.
Disables installing IE components on demand if
Off
needed by a Web page.
Disables installing Web components on demand if
Off
needed by a Web page.
Off Disables the Microsoft VM compiler.
Disables playback of media content in the IE media
On
bar.
Off Disables music and other sounds.
Disables animations.
Off Disables video clips.
Automatically checks a Web site's certificate to see
On whether it has been revoked before accepting it as
valid.
Automatically verifies and displays the identity of
On
programs you download.
Disables saving secured information in your
On
Temporary Internet Files folder.
Automatically clears the Temporary Internet Files
On
folder when you close the browser.

Table 6.3: Advanced changes made by Internet Explorer Enhanced Security Configuration.

The browsing experience will be very restrictive while Internet Explorer Enhanced Security
Configuration is enabled. If you use Web-based tools or Web pages with active scripting for
systems administration, you will need to add these sites to either the Local Intranet Zone or
Trusted Sites Zone. To make zone changes easier, Microsoft adds an Add this site to… selection
to the IE File menu when Internet Explorer Enhanced Security Configuration is enabled. Also, if
you encounter a Web page that uses active scripting, a warning dialog box, which Figure 6.3
shows, gives you quick access to the Add to Trusted Sites interface.

132
 Chapter 6

Figure 6.3: Internet Explorer Enhanced Security Configuration’s enhanced security configuration dialog box.

Managing Approved ActiveX Controls

Regardless of whether Internet Explorer Enhanced Security Configuration is enabled, the
Limited Users and Restricted Users groups are prevented from installing any ActiveX controls or
other active Web code on a terminal server—members of these groups simply do not have write
access to the locations on the file system where the controls are stored.
There are, of course, many cases in which your users will need to access Web pages that use
active code in the course of their normal work. As an administrator, you will need to manage
these approved controls. You can do so using several methods. To manually install a control for
users:
1. Log on to the terminal server using an administrative account, and use IE to browse to the
Web site containing the control.
2. If Internet Explorer Enhanced Security Configuration is enabled, you will receive the
security configuration dialog box warning. Either click Add… to add the site to your
trusted sites list or select Add this site to… from the File menu and add the site to the
Local Intranet Zone.
3. Another dialog box will appear, prompting you to accept and install the control; select the
Always trust… check box, which Figure 6.4 shows, and click OK.
4. The control is now installed for all users on the terminal server.

133
 Chapter 6

Figure 6.4: Security warning when installing an active Web control.

For administering a large number of terminal servers, you will not want to manually install
controls on each server. To automate the installation process, you can either include the controls
in your base image (if you are using a server cloning process such as Sysprep) or you can capture
the files contained in the control and repackage them into MSI files to use Group Policy to install
them on your servers. Which method you choose will depend on your environment and software
distribution methods as well as the frequency at which new or updated controls are required in
your environment.

Internet Explorer Enhanced Security Configuration applies only to IE. If you use a third-party Internet
browser, you will need to implement a separate security model.

Implementing Windows Automatic Updates

The Internet Explorer Enhanced Security Configuration can help protect you from malicious
code found on Web pages—worms and viruses can be designed to take advantage of security
flaws that are discovered in Windows over time. Microsoft is proactive in providing patches and
updates to plug discovered security holes, but you are responsible for installing these updates on
your systems. In the days of NT 4.0, this meant subscribing to the Microsoft Security Bulletin
and frequently checking the Microsoft Security Web page for new updates and information, then
downloading any critical patches and distributing them to your servers and workstations.
Since the release of W2K3 and Windows XP, Microsoft has included the Windows Automatic
Updates client. WS2K3 also includes this service. With Windows Automatic Updates, you can
configure your servers and workstations to download and install any updates that are deemed
critical by Microsoft. The Automatic Updates Client is very versatile and can be configured to fit
most situations.

134
 Chapter 6

You can configure Automatic Updates manually or via Group Policy. For manual configuration,
access the System Control Panel applet, and select the Automatic Updates tab (see Figure 6.5).

Figure 6.5: Configuring Automatic Updates.

Through this interface, you can enable or disable Automatic Updates, and configure the mode in
which the client operates. The available modes are:
• Notify before downloading—The client regularly checks for new critical updates. When
one is available from Microsoft, the client places a notification icon in the system tray
whenever an administrator is logged on to the server. The administrator clicks on this
icon to begin the download and install the update.
• Automatically download but notify before installing—The client regularly checks for
new critical updates. When one is available, the client automatically downloads the
update, then places a notification icon in the system tray whenever an administrator is
logged on to the server. The administrator clicks on the icon to begin the installation.
• Automatically download and install at a specific time—The client regularly checks for
new critical updates. When one is available, the client cues up the update for installation
at the next specified day and time.

135
 Chapter 6

You can also configure Automatic Updates via Group Policy. In the Group Policy Object Editor,
drill down to Computer Configuration, Administrative Templates, Windows Components,
Windows Update. Figure 6.6 shows the available settings.

Figure 6.6: Configuring Automatic Updates through Group Policy.

The Configure Automatic Updates setting specifies the mode and schedule. It offers the same
options as the System Control Panel applet. You can specify the mode and, if automatic
installation is selected, the day(s) and time that the installation should take place.
The next setting, Specify intranet Microsoft update service location, redirects the Automatic
Updates client to an internal Software Update Services (SUS) server.

We will explore SUS in more detail in the next section.

Reschedule Automatic Updates scheduled installations specifies how long after boot the service
should wait before installing updates if the computer was shut down at the last scheduled
installation time. This setting is very useful on workstations, but isn’t often necessary on servers.
Finally, the No auto-restart for scheduled Automatic Updates installations setting suppresses the
reboot (if the update being installed requires one). This setting is helpful if you are running
automated reboot scripts on your terminal servers and do not want to reboot twice on nights that
critical updates are installed.
When configuring Automatic Updates, there are some factors to consider. If your servers are
used only during business hours, it is very easy to set up an automatic installation schedule.
However, if your servers are in use 24 × 7, stagger the installation schedule so that not all servers
are rebooting at the same time. You can use a scheduled task to disable logons in advance of the
scheduled installation time so that the server has a chance to drain before updates are installed
and the server is rebooted.

136
 Chapter 6

In a very large environment, you can create multiple GPOs filtered by security group, each
specifying a different installation schedule. This way, you can group your servers by which day
they install updates.

When using multiple GPOs to schedule Automatic Updates, place the first GPOs in the policy
processing order to apply to the Authenticated Users group, then higher GPOs to be filtered by
security group. This way, if a server is not in a specific group, it will receive the default schedule and
receive updates.

Using SUS
In large or mission-critical environments, you might want the ability to select which critical
updates are necessary in your environment or have the ability to test updates in a lab before
installing them on your production servers. To meet these requirements, Microsoft provides
SUS.
SUS is installed on a Win2K IIS or WS2K3 Application Server, and takes the place of
Microsoft’s own Automatic Updates site. You then use a GPO to redirect the Automatic Updates
client to your internal SUS server. The client then downloads updates from the SUS server for
installation rather than polling Microsoft for updates.
To install SUS, download the installer from the Microsoft Web site (the most recent location is at
http://www.microsoft.com/windows2000/windowsupdate/sus/default.asp). The default
installation stores updated source files in C:\sus\content and is set to require you to manually
approve new versions of previously approved updates before clients can download and install
them. You can change these options either after the installation is complete or by selecting a
custom installation from the Windows Installer wizard. Figures 6.7 and 6.8 show the installation
options dialog boxes.

137
 Chapter 6

Figure 6.7: Specifying where to store update source files during the installation of SUS.

If your application server is tight on disk space and your terminal servers have an open
connection to the Internet, you can choose to leave the update source files on Microsoft’s update
servers. You will still be able to selectively approve and test updates, but you will not have a
local copy of the source files.
Occasionally, Microsoft releases an updated version of a previously released patch. SUS allows
you to treat the updated version as an entirely new patch (which you will want to do if you are
testing updates in a lab before deploying them) or automatically approve the new version if you
have already deployed the original version (see Figure 6.8).

138
 Chapter 6

Figure 6.8: Configuring manual or automatic approval of new versions of previously approved updates.

After SUS is installed, you can configure and manage the service through a Web interface
located at http://localhost/susadmin or remotely from http://<servername>/susadmin. Through
the interface, you can configure a proxy server (if one is required for the SUS server to access
Microsoft’s Web site), specify the name that the clients will use to access the SUS server, select
whether to synchronize updates from Microsoft or from another SUS server (useful if you have
more than one SUS server for fault tolerance), and change the two options you set during
installation.
If you are using a local store for update source files, you can select which localized versions of
the updates you want to download. Be sure to select only the languages of the clients you
support, as the additional source files can consume a large amount of disk space and increase the
time it takes to synchronize the server. Figure 6.9 shows the section of the options page used to
specify localized updates.

139
 Chapter 6

Figure 6.9: Specifying SUS options.

The SUS administrative interface is also where you initiate synchronization. During
synchronization, the server downloads the latest catalog of updates from Microsoft as well as the
source files for the updates (if you have selected a local store). After performing a
synchronization manually to confirm that your proxy configuration is valid, you should set up a
synchronization schedule so that your SUS server is always up to date.
Once your SUS server is synchronized, you use the administrative interface to approve new
updates. These approved updates will be downloaded and installed at the next scheduled
installation window on all clients configured to use the SUS server. Figure 6.10 shows the
approval interface.

140
 Chapter 6

Figure 6.10: Approving updates on an SUS server.

SUS provides a description of each update, a link to the installation details, and a list of the OSs
to which the update applies. In the details screen, there is a hyperlink to the Microsoft security
bulletin for the vulnerability, which provides additional information you can use to determine
whether the update is required in your environment.

If you plan to test updates before approving them for distribution to your production systems, you can
either download the updates from the Windows Update Web site manually or set up two SUS
servers—one for your lab and one for production clients. Approve a new update on the lab server
first, perform your testing, then approve it on the production server.

To configure your terminal servers to pull approved updates from an SUS server, configure a
GPO in the same way you would for Microsoft Automatic Updates but use the Specify Intranet
Microsoft update service location setting to configure the URL of your SUS server. The
Automatic Updates client will now look to SUS for updates.
Implementing SUS puts you in control of which updates are installed on your terminal servers.
Although this method gives you the opportunity to test updates before installation, it also
requires that you manually approve updates. You must be vigilant in staying up to date on
Microsoft security bulletins or frequently check your SUS server for new updates awaiting
approval. You do not want to be caught with a security exposure that could have been prevented
by simply approving an update.

141
 Chapter 6

As of this writing, the Automatic Updates client has one major flaw. Once an update or set of updates
is downloaded and cued for installation, the client will not poll for new updates again until the first set
is installed. Thus, you should either set up a daily installation schedule or only approve updates on
your SUS server on a weekly basis. This way, when the client polls SUS, it will download and install
all pending updates.

Deploying Service Packs and Hotfixes

In addition to using security patches, Microsoft keeps Windows at its best through service packs
and hotfixes. These should be thoroughly tested before deploying them to your production
servers—test service packs because of how large the scope of the changes are and test hotfixes
because of Microsoft’s limited support of them.

Using Group Policy to Deploy Service Packs

Once you determine that a service pack is ready for prime time, you need a way to deploy it to
your terminal servers. Beginning with Win2K, Microsoft began including an MSI file that you
can use to assign service packs via Group Policy. Doing so saves you the time of manually
installing the service pack on each server.

The UPDATE.MSI file should only be used for deploying a service pack via Group Policy. Never
install a service pack manually with the MSI file—use UPDATE.EXE instead.

You assign a service pack to a computer in the same way you would any other piece of machine-
based software. Begin by extracting the service pack files to a network share that can be accessed
by all your terminal server computer accounts. To perform the extraction, launch the service
pack executable with a -X switch (for example, WS2K3SP1.EXE –X). You will then be
prompted for the location to which the files should be extracted.
Next, use the Group Policy Management Console to edit the GPO that will assign the service
pack to your computers. Drill down to Computer Configuration, Software Settings, Software
installation. Right-click this node, and select New, Package. You will then be prompted to select
an MSI package to deploy. Enter the UNC path to the UPDATE.MSI file in the folder to which
you extracted the service pack, and click Open.
You will be offered the option to assign the package with default settings or open the advanced
dialog box. You can select Assigned, then click OK—there are no advanced settings that need to
be specified when deploying a service pack.
The next time a terminal server that is configured to receive the GPO reboots, the service pack
will be installed. If you are performing regular maintenance scripts on your terminal servers, you
can relax knowing that within a week all servers will have the service pack installed.
Microsoft always makes service packs inclusive of updates found in previous service packs. This
way, you only need to install one service pack when building a new server. When you are ready
to deploy a new service pack, you will need to remove the GPO assignment of the previous one
so that both service packs are not installed on new systems.

142
 Chapter 6

You do not need to uninstall a previous service pack before installing the new one, just remove the
assignment.

To remove the assignment of the earlier service pack, use Group Policy Management Console to
edit the GPO used to assign the service pack. Right-click the package, and select All Tasks,
Remove. You are then prompted with the dialog box that Figure 6.11 shows, giving you the
option to either uninstall the software from all computers that are managed by the GPO or simply
prevent new installations; select the latter option.

Figure 6.11: Removing software assigned via GPO.

Once you have removed the assignment for the old service pack, you can create the assignment
of the new service pack. At the next reboot, all servers will receive the latest pack, either over the
previous one or as the fist pack on a new server.

Deploying Hotfixes
Windows Automatic Updates and SUS will only take care of critical and security updates. If you
determine that one or more non-critical updates are needed in your environment, you need a way
to deploy them to your servers.
For new servers, the best method is to integrate the hotfixes into your server build process. If you
are using a server-cloning process or RIS images, this task can be accomplished by either
installing them manually before running Sysprep or Ripprep. If you are building servers with an
unattended install process, you can add them via a CMDLINES.TXT file.

For additional information about integrating hotfixes into an unattended installation of Windows, see
the Hotfix Installation and Deployment Guide found at
http://www.microsoft.com/Windows2000/downloads/servicepacks/sp3/hfdeploy.htm.

Microsoft does not, however, provide a clear method to deploy hotfixes to multiple existing
servers. The deployment guide only covers manual installation from a network source. This
process is fine in smaller environments, but for large terminal server farms, you will want to
automate the installation. The following suggested methods for doing so will not work in all
situations and is not a comprehensive list. Select the best option for your situation and
environment.

143
 Chapter 6

Using a ZAP File

If you need to install a single hotfix at a time, a ZAP file is a good option. ZAP files are used to
install non-MSI–based software via Group Policy. ZAP files are simply text files containing the
information needed to install the application. Listing 6.1 provides a sample ZAP file.
[Application]
; Only FriendlyName and SetupCommand are required,
; everything else is optional.

; FriendlyName is the name of the program that

; will appear in the software installation snap-in
; and the Add/Remove Programs tool.
; REQUIRED
FriendlyName = "Hotfix Q911001"

; SetupCommand is the command line used to

; Run the program's Setup. If it is a relative
; path, it is assumed to be relative to the
; location of the .zap file.
; Long file name paths need to be quoted. For example:
; SetupCommand = "long folder\setup.exe" /unattend
; or
; SetupCommand = "\\server\share\long _
; folder\setup.exe" /unattend
; REQUIRED

SetupCommand = “Q######_WS2K3_SP1_x86_en.exe” /M

; Version of the program that will appear

; in the software installation snap-in and the
; Add/Remove Programs tool.
; OPTIONAL
DisplayVersion = 1.0

; Version of the program that will appear

; in the software installation snap-in and the
; Add/Remove Programs tool.
; OPTIONAL
Publisher = Microsoft

Listing 6.1: A sample ZAP file for installing a hotfix.

The main disadvantage of using ZAP files to install hotfixes is that the server will reboot after
each hotfix installation. Thus, this method is not useful for installing multiple hotfixes.

The command-line arguments for all Microsoft hotfix installer programs are:
/F Forces any open applications to close when the hotfix reboots the computer
/N Does not back up files for removing the hotfix
/Z Does not restart the computer after the installation is completed
/Q Uses quiet mode; no user interaction is required
/M Uses unattended setup mode
/L Lists installed hotfixes

144
 Chapter 6

Using a Shutdown Script

Most hotfixes require you to reboot the server after installation (or at the end of a string of
hotfixes), so a shutdown script is a perfect option for installing them. You don’t want to install
the hotfixes every time the server shuts down, so you will need to script in some checks before
calling the installation program. The easiest way to check whether a hotfix is already installed is
to query the registry. All Microsoft hotfixes register themselves in two locations in the registry:
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\WS2K3\<SPx>\<HotfixN
ame>—Where <SPx> is the pending service pack that will contain the hotfix and
<HotfixName> is the Microsoft Knowledge Base article that describes the hotfix
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Hotfix\<HotfixName>—Where <HotfixName> is the Microsoft
Knowledge Base article that describes the hotfix
Listing 6.2 shows a sample Visual Basic script you can use to install multiple hotfixes.
On Error Resume Next
Set WshShell = WScript.CreateObject("WScript.Shell")

WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Updates\WS2K3\SP1\Q819639\Des
cription")
If Err then
Hotfix1="Q819639_WS2K3_SP1_x86_en.exe /Z /M"
WshShell.Exec(Hotfix1)
End If

WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Updates\WS2K3\SP1\KB818529\De
scription")
If Err then
Hotfix2="KB818529_WS2K3_SP1_x86_en.exe /Z /M"
WshShell.Exec(Hotfix2)
End If

Listing 6.2: A sample Visual Basic script for installing multiple hotfixes.

To set the script as a shutdown script, use the Group Policy Management Console to edit a GPO
that applies to your terminal servers. Drill down to Computer Configuration, Windows Settings,
Scripts (Startup/Shutdown), and double-click Shutdown in the right pane. Doing so will open the
Script Properties dialog box that Figure 6.12 shows.

145
 Chapter 6

Figure 6.12: Configuring a shutdown script via a GPO.

In this dialog box, click Show Files and copy your script file and all the hotfix installation files to
the folder. Then use the Add button to set the script file to run at system shutdown. Every time
your servers are shut down or rebooted, the script will install any hotfixes not already present on
the system.

Although hotfixes have built-in logic to prevent them from being installed on a system with a newer
service pack, disable or update your hotfix script after you deploy a new service pack to reduce the
overhead—no need to spend the time attempting to install fixes that are not needed.

146
 Chapter 6

Virus Protection Software Best Practices

Virus protection software is you last line of defense against malware. You can implement filters
on your corporate email system, use an email client such as Microsoft Outlook 2002 that blocks
all executable attachments, and implement strong firewall and proxy server rules on your Internet
connection. Regardless, a virus will always find its way into the environment.
Virus protection software works by scanning both individual files and active processes in
memory and comparing them with a database of known signatures. Most virus protection
software protects you from all three types of malware; however, the protection is only as good as
the database. You must keep the database of virus definitions updated, so be sure to select a
software product that provides you with a method of updating the database.
The following list highlights best practices when implementing and configuring virus protection
software:
• Select a product that allows you to update virus definitions without rebooting the server.
• If your terminal servers are mission critical, select a product that enables you to pull
updates from an internal source, giving you the opportunity to test and validate the
updates before deploying them on production servers.
• Many virus protection products install a status icon into the system tray. After checking
with the vendor, disable the icon (usually by removing a value from the
HKEY_LOCAL_MACHINE\Software\Micrrosoft\Windows\CurrentVersion\Run
registry key). Doing so will reduce the load placed on your server by having the status
program running in every user session.
• In addition to “real-time” scanning (scanning every file that users access and processes in
memory), most products perform scheduled scans of every file on the system. Be sure to
schedule these scans during off-hours.

Putting It All Together

As you can see, there are several options available to help keep your terminal servers secure and
virus-free. In this section, we’ll explore two examples of how these options can be implemented.

Example One: Anytown Little Theatre

David is a terminal server administrator at a local company. During evenings and weekends, he
volunteers doing systems administration and tech-support work at a local community theater,
Anytown Little Theatre. To help keep costs down and the network as stable as possible, he used
some grant money to set up a terminal server infrastructure for the theatre. Figure 6.13 illustrates
the network.

147
 Chapter 6

Figure 6.13: Anytown Little Theatre network.

The infrastructure consists of nine thin clients used by the theatre staff, a terminal server, and a
personal router/firewall connected to a DSL line. Users connect to the terminal server and
receive a full desktop environment with all the needed applications installed. They store their
documents in their My Documents folders on the terminal server, and access a public share for
common documents. The share is also on the terminal server. User profiles, the public share, and
the System State are backed up nightly at 1AM to an external hard disk connected to the server.
David wants to keep the network as stable and secure as possible, so he implements the
following security measures:
• The firewall is configured to use Network Address Translation (NAT) and block inbound
requests. This setup allows the staff to surf the Web, but prevents worms from attacking
the server from the Internet.
• All theatre staff members are set up as Limited Users on the terminal server. This setup
prevents them from installing software or ActiveX controls but does not apply Internet
Explore Enhanced Security Configuration to them, so they can browse the Internet
without receiving unnecessary warnings and error messages.
• The Automatic Updates client on the server is configured to automatically download and
install critical updates from Microsoft on a nightly basis at 4AM. Automatic reboots are
allowed.
• Virus protection software is installed on the server and configured to download updated
definition files from the vendor’s Web site automatically every night at 3AM.
• There is only one server, so David installs service packs and hotfixes manually.

Example Two: BigBusiness, Inc.

BigBusiness, Inc is a midsized company of about 2000 employees. Because of the variety of
tasks users perform, each user has a Windows XP workstation with applications installed locally.
There are two mission-critical applications that receive frequent updates and access large
databases of customer data.

148
 Chapter 6

To optimize performance and make deploying application updates easier, BigBusiness’ IT staff
has implemented a terminal server Session Directory Farm to serve the two applications to end
users. Users access the applications through a customized Remote Desktop Web Connection
Web page that connects the users to the specific applications instead of a terminal server desktop.
Figure 6.14 shows BigBusiness’ network.

Figure 6.14: The network of BigBusiness, Inc.

To keep the terminal servers as stable and secure as possible, BigBusiness’ IT staff has set up the
following configuration:
• The corporate firewall blocks all inbound traffic to the terminal servers.
• All users are configured as Limited Users on the terminal servers, and Internet Explorer
Enhanced Security Configuration is enabled for all users. Because users do not access IE
on the server, this configuration can be enabled without impacting the end-user
experience.
• Virus protection software is installed on all the terminal servers and configured to pull
updates from an internal FTP site. Virus definition files are tested in the lab before being
uploaded to the FTP site.
• Two SUS servers have been implemented—one for production and one for the lab. New
critical updates are first approved on the lab SUS server. The lab terminal server’s
Automatic Updates client is configured to pull updates daily at 1AM from the lab SUS
server. The day after a new update is approved, the lab server and its applications are
tested. If the update does not impact the server or applications, it is then approved on the
production SUS server.
• The production servers are grouped by maintenance schedules. Each afternoon a script
runs on a specific group of servers, disabling new logons. That night, the Automatic
Updates client on that group of servers is configured via Group Policy to download and
install new updates from the production SUS server, then reboot. Within a week, all
servers receive any new updates.

149
 Chapter 6

• In the event of a serious threat, the Group Policies can be changed to have the Automatic
Updates client on all servers pull updates that night. This way, a new critical update can
be deployed to all servers within one day.
• When a new service pack is available, it is thoroughly tested in the lab. Once it is deemed
stable, it is assigned to the production servers via GPO. At the next maintenance night for
each group of servers, the service pack is installed during the automatic reboot. Within a
week, all servers have received the new service pack.

Summary
The enhanced security model of WS2K3 and the inclusion of the Automatic Updates client make
it easier to keep your servers secure and updated with the latest security patches. You can use
Group Policy and the Internet Explorer Enhanced Security Configuration to further protect your
terminal server systems from malicious code.
“Do more with less” is the slogan that Microsoft used to launch WS2K3. With the new features
and enhancements in Terminal Services, terminal server administrators can certainly take this
slogan to heart. We now have native methods of grouping servers into load-balanced farms,
managing their configuration and behavior through Group Policy, and distributing connection
files to our users.
Through the course of this book, I have introduced you to the new features and taken you
through the process of building a terminal server infrastructure, both small and large. You have
seen how to enable the Terminal Services Role, set up a Session Directory, assign applications to
your servers through Group Policy, and configure the Automatic Updates client to pull updates
from either Microsoft or an SUS server. I hope you see how powerful Terminal Services can be,
and how easy it is to maintain if set up and configured properly.
From the smallest business to the largest corporation, Terminal Services provides a powerful tool
for centralizing your computing needs. It is versatile enough to provide entire desktop
replacements or give users access to a single application. With a little research and planning, you
are ready to begin building terminal server infrastructures that are stable, highly available, easy
to scale, and easily managed.

150
 Appendix

Appendix A: Terminal Services Clients

Remote Desktop Connection for Windows Server 2003
http://www.microsoft.com/downloads/details.aspx?FamilyID=a8255ffc-4b4a-40e7-a706-
cde7e9b57e79&DisplayLang=en

If you need the client in MSI format (for distribution via Group Policy) use
msrdpcli.exe /c
from a command prompt.

Remote Desktop Connection Client for Mac

http://www.microsoft.com/downloads/details.aspx?FamilyID=c669fcf7-c868-4d45-95f3-
f75ddd969232&DisplayLang=en
Remote Desktop Web Connection
http://www.microsoft.com/downloads/details.aspx?FamilyID=e2ff8fb5-97ff-47bc-bacc-
92283b52b310&DisplayLang=en
Terminal Services Client for PocketPC (2000 and 2002)
http://www.microsoft.com/windowsmobile/resources/downloads/pocketpc/tsc.mspx

151
 Appendix

Appendix B: Important URLs

Windows Server 2003 Terminal Services Technology Center
http://www.microsoft.com/windowsserver2003/technologies/terminalservices/default.mspx
Microsoft TechNet: Terminal Services
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver
2003/technologies/terminal/default.asp
Terminal Server Sizing Sample Scripts
http://www.microsoft.com/windows2000/techinfo/administration/terminal/loadscripts.asp
Windows Server 2003 Terminal Server Licensing
http://www.microsoft.com/windowsserver2003/techinfo/overview/termservlic.mspx
Terminal Services Client Access License Activation Web site
https://activate.microsoft.com
Software Update Services (SUS)
http://www.microsoft.com/windows2000/windowsupdate/sus/default.asp

152
 Appendix

Appendix C: Registry Changes

Listed here are all of the registry changes described in Chapter 2. I have formatted them to allow
you to copy and paste them into a .REG file for easy import.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Policies\Explorer]
"LinkResolveIgnoreLinkInfo"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server]
"IdleWinStationPoolCount"=dword:00000005
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\WinStations\RDP-Tcp\UserOverride\Control Panel\Desktop]
"AutoEndTasks"="1"
"CursorBlinkRate"="-1"
"DragFullWindows"="0"
"MenuShowDelay"="10"
"WaitToKillAppTimeout"="20000"
"SmoothScroll"=dword:00000000
"Wallpaper"="(none)"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\WinStations\RDP-Tcp\UserOverride\Control
Panel\Desktop\WindowMetrics]
"MinAnimate"="0"

153
 Appendix

Appendix D: Script Reference

USRLOGON.CMD
The following code is the modified USRLOGON.CMD that takes advantage of Win2K’s ability
to map the home directory to the user’s folder. Deletions are in STRIKETHROUGH and
additions are in BOLD. In order to use this script, you should set your ROOTDRIVE to the same
drive letter that you use for your users’ network home directories.
@Echo Off

Call "%SystemRoot%\Application Compatibility

Scripts\SetPaths.Cmd"
If "%_SETPATHS%" == "FAIL" Goto Done

Rem
Rem This is for those scripts that don't need the RootDrive.
Rem

If Not Exist "%SystemRoot%\System32\Usrlogn1.cmd" Goto cont0

Cd /d "%SystemRoot%\Application Compatibility Scripts\Logon"
Call "%SystemRoot%\System32\Usrlogn1.cmd"

:cont0

Rem
Rem Determine the user's home directory drive letter. If this
isn't
Rem set, exit.
Rem

Cd /d %SystemRoot%\"Application Compatibility Scripts"

Call RootDrv.Cmd
If "A%RootDrive%A" == "AA" End.Cmd

Rem
Rem Map the User's Home Directory to a Drive Letter
Rem

154
 Appendix

Rem
Rem Subst the user’s profile directory onto the ROOTDRIVE
Rem if it is not already mapped as the Home Directory
Rem

if /I "%rootdrive%" == "%homedrive%" goto NoSubst

:DoSubst

Net Use %RootDrive% /D >NUL: 2>&1

Subst %RootDrive% "%HomeDrive%%HomePath%"
if ERRORLEVEL 1 goto SubstErr
goto AfterSubst
:SubstErr
Subst %RootDrive% /d >NUL: 2>&1
Subst %RootDrive% "%HomeDrive%%HomePath%"
:AfterSubst

:NoSubst

Rem
Rem Invoke each Application Script. Application Scripts are
automatically
Rem added to UsrLogn2.Cmd when the Installation script is run.
Rem

If Not Exist %SystemRoot%\System32\UsrLogn2.Cmd Goto Cont1

Cd Logon
Call %SystemRoot%\System32\UsrLogn2.Cmd

:Cont1

:Done

155
 Appendix

TSSHUTDN Wrapper
TSSHUTDN.EXE is the native utility used to shut down or reboot a terminal server. This utility
warns users that the terminal server is about to shut down so that they have time to save their
work. It then executes a logoff command within each session, and finally shuts down the server.
Unfortunately, the default behavior of the utility is to shut down, and not reboot, the server in 30
seconds.
I wrote this wrapper to prevent accidental shutdowns. Copy the following code, and save it as a
VBS file in the SYSTEM32 directory. To launch the wrapper, type the VBS file’s name at a
command prompt (I name the file TSSHUTDOWN.VBS):
' AUTHOR: Greyson Mitchem, The Definitive Guide to WS2K3 TS
'
' This VBS file is a safety wrapper for the native
' TSSHUTDN.EXE that shuts down or reboots a TS.
' This script will collect the parameters for
' the tsshutdn command.

set oShell=CreateObject("Wscript.Shell")
set oNet=CreateObject("Wscript.Network")

returnkey=msgbox("This script collects the parameters needed

to"&VBCRLF&"correctly shutdown or reboot a Terminal
Server."&VBCRLF&"You may abort the process at any time by hitting
CANCEL."&VBCRLF&VBCRLF&"Do you wish to continue?", VBOKCancel +
VBInforamtion, "TS Shutdown")
IF returnkey=VBCancel THEN Wscript.Quit(1)

Server=InputBox("Enter the name of the server you wish to

Reboot/Shudown:", "Server Name", oNet.ComputerName)
if trim(Server)="" then Wscript.Quit(1)

bRestart=MSGBox("Do you wish to have the server

reboot?"&VBCRLF&VBCRLF&"Clicking NO will PowerDown the system
without rebooting.", VBYesNoCancel + vbQuestion, "Reboot or
PowerDown")
Select Case bRestart
Case vbYes
sOption="/REBOOT"
Case vbNo
sOption="/POWERDOWN"

156
 Appendix

Case vbCancel
Wscript.Quit(1)
End Select

Wait=InputBox("Please enter the number of seconds to give users

to finish working before forcibly logging them off:", "Wait
Time", "60")
if trim(Wait)="" then Wscript.Quit(1)

Delay=InputBox("Please enter the number of seconds to wait after

all users have logged off before shutting down the system:",
"Wait Time", "30")
if trim(Delay)="" then Wscript.Quit(1)

' All Parameters have been collected. Now we build the comand
line.

ShutdnCMD="tsshutdn.exe "&wait&" /server:"&Server&" "&sOption&"

/Delay:"&Delay&" /v"

oShell.RUN(ShutdnCMD)

Wscript.Quit(0)

If you want to create a shortcut to the wrapper, make the target

wscript %systemroot%\system32\<scriptname.vbs>

157
 Appendix

Maintenance Reboot Script

The following code is an example of a script that you can use to perform a maintenance reboot
on a terminal server. Your circumstances—number of users, roaming profile environment,
applications installed, and so on—will determine the frequency that you need to schedule
maintenance reboots. In order for this script to run correctly, you need two additional files in the
directory with the script: the resource it utility Sleep.EXE and a text file named yes.txt with the
letter Y as its contents:
REM
REM Sending a message to any currently logged-on users
REM warning them that a maintenance reboot will occur
REM in 10 minutes.
REM

change logon /disable

msg * Please save your work and log off. Maintenance reboot in 10
minutes.

REM Pausing for 5 minutes

sleep 300

REM 5 minute warning

msg * Save your work now and log off. Maintenance reboot in 5
minutes

REM Pausing for 5 minutes

sleep 300

REM 30 second warning

msg * Maintenance reboot in progress. You will be logged off in
30 seconds

REM Pausing for 30 seconds

sleep 30

REM Logging all users off

logoff rdp-tcp < yes.txt

158
 Appendix

REM Stopping the Print Spooler service and deleting any

REM orphaned files.
net stop spooler
del %systemroot%\system32\spool\printers\*.* /q

REM Rebooting the TS

tsshutdn /REBOOT

159
 Appendix

Appendix E: Terminal Services Command Line Reference

Change User
To toggle the system between Install and Execute Modes, use the following commands. Switches
the terminal server into Install Mode:
CHANGE USER /install
Switches the terminal server into Execute Mode:
CHANGE USER /execute

Change Logon
Enables or disables new logons to the terminal server; does not affect currently logged on users.
To enable new logons:
CHANGE LOGON /enable
To disable new logons:
CHANGE LOGON /disable

When you reboot a terminal server, logons are automatically enabled (even if they were disabled
when you shut down the system).

Query Terminal Servers

Lists all active terminal servers in the current or specified domain:
QUERY TERMSERVER [servername] [/domain:domain] [/address]
[/continue]
where:
• servername is the name of a specific terminal server that you want to query
• /domain:domain is the name of the domain you want to query (the default is to query the
current domain)
• /address includes the IP address of each server in the output
• /continue does not pause between screens of output

160
 Appendix

Query Session
Lists all current sessions on a specific terminal server:
QUERY SESSION [sessionname | username | sessionid]
[/server:servername] [/mode] [/flow] [/connect] [/counter]
where:
• sessionname is the name of a specific session that you want to query
• username is the name of the specific user you want to query
• sessionid is the ID of the specific session you want to query
• /server:servername is the name of the server you are querying—the default is the server
you are logged on to
• /mode outputs the current line settings
• /flow outputs the current flow control settings
• /connect outputs the current connection settings
• /counter outputs the counter information for the server

Query User
Lists all current users with sessions on a terminal server:
QUERY USER [username | sessionname | sessionid]
[/server:servername]
where:
• sessionname is the name of a specific session that you want to query
• username is the name of the specific user you want to query
• sessionid is the ID of the specific session you want to query
• /server:servername is the name of the server you are querying—the default is the server
you are logged on to

You can shorthand QUERY USER to QUSER

161
 Appendix

Query Process
Lists processes running on the terminal server (can be filtered to a specific session):
QUERY PROCESS [* | processid | username | sessionname | /id:nn |
programname] [/server:servername] [/system]

where:
• * lists all processes on the terminal server
• processed lists information about only the specific process ID
• username lists processes running under the context of a specific user
• sessionname lists processes running under the context of a specific session
• /ID:nn lists processes running in the session with the specified session ID number
• programname lists all processes started by the specified executable
• /server:servername is the name of the server you are querying—the default is the server
you are logged on to
• /system lists processes running under the system context

Logoff
Logs a user out of the terminal server and deletes the session. If no arguments are included, the
command logs you out:
LOGOFF [sessionid | sessionname] [/server:servername] [/v]
where:
• sessionid is the ID of the session you want to logoff
• sessionname is the name of the session you want to logoff
• /server:servername specifies the name of server on which the session you want to logoff
is running (the default is the server to which you are connected)
• /v displays verbose information about actions being performed

162
 Appendix

Message
Sends a popup message to a user or users on the terminal server:
MSG [username | sessionname | sessionid | @filename | *]
[/server:servername] [/time:seconds] [/v] [/w] message
where:
• username is the name of the user to whom you are sending the message
• sessionname is the session name to which you want to send the message
• sessionid is the ID number of the session to which you want to send the message
• @filename is the name of a text file containing usernames, sessionnames, or session IDs
to which you want to send the message
• * sends the message to all users on the current or specified server
• /server:servername specifies the server where recipients of the message are connected
• /time:seconds the number of seconds to display the message before the popup closes
itself
• /v displays information about the message as it is sent
• /w causes the popup window to wait for the user to click OK before closing
• message is the text of the message to send

Reset Session
Terminates a user’s session without warning the user, and without performing a graceful logoff;
can be used to terminate a hung session:
RESET SESSION [sessionname | sessionid] [/server:servername] [/v]
where:
• sessionname is the name of a specific session that you want to reset
• sessionid is the ID of the specific session you want to reset
• /server:servername is the name of the server on which the session resides
• /v displays verbose information about actions being performed

163
 Appendix

Shadow
Begins a remote control session:
SHADOW [sessionname | sessionid] [/server:servername] [/v]
where:
• sessionname is the name of a specific session that you want to shadow
• sessionid is the ID of the specific session you want to shadow
• /server:servername is the name of the server on which the session resides
• /v displays verbose information about actions being performed

Terminal Services Profile

Populates the Terminal Services profile path of a specified user; can also be used to copy the
Terminal Services profile contents from one user to another (this command requires
Administrator rights):
TSPROF /update [/domian:domainname | /local] /profile:path
username

TSPROF /copy [/domian:domainname | /local] [/profile:path]

src_user dest_user

TSPROF /q [/domian:domainname | /local] username

where:
• /update populates the user domainname\username’s Terminal Services profile path with
path
• /copy copies the Terminal Services profile from src_user to dest_user and, if specified,
updates dest_user’s Terminal Services profile path with path
• /q displays the Terminal Services Profile path for the specified user

164
 Appendix

Terminal Server Shutdown

Shuts down or reboots a terminal server in an orderly fashion, giving any current users the
opportunity to save their work and logoff:
TSSHUTDN [wait_time] [/server:servername] [/reboot] [/powerdown]
[/delay:logoffdelay] [/v]
where:
• wait_time is the number of seconds to wait after notifying the users that the terminal
server is about to shut down before forcibly logging them off (the default is 30 seconds)
• /server:servername is the name of the server to reboot/shutdown (the default is the server
to which you are connected)
• /reboot reboots the server
• /powerdown powers down the server after Windows has shutdown; the server’s BIOS
must support this command
• /delay:logoffdelay the number of seconds to wait after logging out all users before
shutting down the system (the default is 30 seconds)
• /v displays verbose information about actions being performed

See Appendix D for a VBS wrapper for TSSHUTDN to make entering the parameters easier.

Remote Desktop Client Command Line Parameters:

MSTSC [<Connection File>][/v:<server[:port]>] [/console]
[[/f[ullscreen]|[/w:<width> /h:<height>]]|[/Edit”connection
file”][/Migrate]
where:
• <Connection File> specifies the RDP file for the connection
• /v:<server[:port]> specifies the server name or IP address to connect to and the port on
which to connect
• /console connects to the console session of a WS2K3 system
• /f[ullscreen] starts the client in full-screen mode
• /w:<width> /h:<height> specifies a height and width for the connection window
• /edit opens an RDP file for editing
/Migrate migrates legacy Client Connection Manager connections out of the registry and into
RDP files.

165