Chapter 2: Configuring Terminal Services

The Terminal Services (TS) server role enables users to connect to the server and run specific
graphical applications, or to use the full Windows desktop. This capability is useful in a variety
of scenarios, for example, to centralize administration of applications; to exercise greater control
over what users are able to do with an application; to enable users of any of the platform that
support the remote desktop web client to access a Windows desktop or Windows based-
applications. TS can lower support costs because you only have to maintain and upgrade the
application on a few servers rather than hundreds or thousands of end-user computers. It can
facilitate new types of solutions such as allowing mobile users to securely access a Windows
desktop that is located on the corporate network using nothing more than a web browser. In this
chapter you will learn to:

 Configure Windows Server 2008 Terminal Services RemoteApp (TS RemoteApp).

 Configure Terminal Services Gateway.
 Configure Terminal Services load balancing.
 Configure and monitor Terminal Services resources.
 Configure Terminal Services licensing.
 Configure Terminal Services client connections.
 Configure Terminal Services server options.

Configure Windows Server 2008 Terminal

Services RemoteApp (TS RemoteApp)
TS RemoteApp programs appear to be running on the end user’s computer: each has its own
resizeable window and each appears as an item on the Taskbar, but they are actually running on a
TS server. The user does not have access to the full Windows desktop on the TS server, just
specific applications. The applications can be accessed through the full TS client or using the
ActiveX-based client that runs within a web browser.

Installing Terminal Services

There are 5 TS role services, it is very important that you understand the function of each and
how they interact with one another. Only the Terminal Server role service is required to enable
basic RemoteApp functionality but install all five on a server in your practice lab along with any
dependent server roles. The five role services are:

 Terminal Server – TS core functionality is provided by this role service including the ability to
host multiple Windows desktop sessions for remote users.
 TS Licensing – Used for installing, issuing, and monitoring the client access licenses (CALs) that
are required for each user or device to connect to a terminal server.
 TS Session Broker – Provides session load balancing across a farm of TS servers, ensures that
clients are reconnected to their existing session after a brief interruption.
  TS Gateway – Enables authorized users working remotely to connect to TS servers on the
corporate network. This role service requires the Web Server and Network Policy and Access
Services server roles.
 TS Web Access – Enables users to access TS through a website using a web browser and the
ActiveX-based TS client This role service requires the Web Server server role.

The installation wizard will prompt you to provide a lot of information, proceed through the
wizard as follows:

1. On the Specify Authentication Method for Terminal Server page of the installation wizard
specify Require Network Level Authentication and click Next. This provides a higher level of
security by requiring TS clients to authenticate sooner during the process of establishing a
connection to the TS server. This requires that the clients be running Remote Desktop
Connection (RDC) 6.0 and an operating system (OS) that supports the Credential Security
Support Provider (CredSSP) protocol, which means Windows Vista and Windows Server 2008 or
Windows XP with Service Pack 3.
2. On the Specify Licensing Mode page select Configure Later and click Next. Understanding TS
licensing is an important part of preparing for the exam, therefore its covered in its own section
later in the chapter.
3. Accept the defaults for the next two pages of the wizard, on the Choose a Server
Authentication Certificate for SSL Encryption select Choose an existing certificate for SSL
Encryption if one is available, otherwise chose Create a self-signed certificate for SSL
Encryption, click Next.
4. On the Create Authorization Policy for TS Gateway page specify that you will create the policies
later, authorization policies will be covered later in this chapter.
5. Accept the defaults for the remaining pages of the wizard and complete the installation. At this
point you may need to restart the server.

For a production TS server you would now install the applications that end users will be able to
run, you can forego that process in your practice lab.

Configuring RemoteApp Programs

Shortcuts to the TS management tools were created in a folder called Terminal Services was
created in the Administrative Tools folder. For the rest of the chapter, when I will ask you to
launch any of the TS tools I will not specify the folder name if the shortcut is located in the
Terminal Services folder. To add applications to the RemoteApp programs list open TS
RemoteApp Manager, and do the following:

1. Click Add RemoteApp Programs in the Actions pane, and click Next when the wizard launches.
2. Since we have not added any end-user applications select Calculator and Wordpad from the list
of programs and click Next.
3. Click Finish to complete the wizard.

Now you have to decide how to make the programs available to users. You can right-click on
each in the RemoteApp Programs list to see several options, as shown in figure 1:
 Show in TS Web Access to have the applications listed on the TS Web Access web site.
 Create .rdp File to generate a shortcut to the RDC client application that includes connection
information. When a user opens the shortcut the RDC client will connect to the TS server and
open the RemoteApp program. Remote Desktop Protocol (RDP) is the network protocol used for
TS communication. You can distribute the .rdp file by posting on a shared network folder or
copying it to each user’s computer.
 Create Windows Installer Package will also create a shortcut to the RDC client with the
necessary connection settings, however, when the package is installed a few other changes can
be made such as adding a shortcut to the Start menu. You can distribute the package using
group policy or whatever software management program you use.
Figure 1: Configuring RemoteApp Deployment.

Configuring Terminal Services Web Access

Right-click each program and specify Show in TS Web Access, then open TS Web Access
Administration. There are 3 tabs visible: The RemoteApp Programs tab contains the list of
available programs, clicking on one launches the browser-based TS client. The Remote Desktop
tab can be used to launch the browser-based TS client with access to a full Windows desktop, if
the TS server is configured to allow that type of connection. The Configuration Tab is used to
specify which TS server the TS Web Access server will connect to. Note that if the TS Web
Access and TS server hosting the RemoteApp programs are separate systems then you must add
the computer account of the former to the TS Web Access Computers security group on the
later. When users who do not have administrative privileges connect to the TS Web Access
server they will only see the first two tabs, as shown in figure 2. The default URLs are
http://<hostname>/ts and https://<hostname>/ts, where <hostname> is the fully qualified domain
name (FQDN) of the TS Web Access server.

Figure 2: Connecting to a TS Web Access web site.

TechNet Virtual Labs: Terminal Services and Virtualization Coming Together

For decades software companies have given away evaluation versions of their products to help
show potential customers the value of their solutions. Microsoft has been doing this too,
manufacturing DVDs and packaging them in slim cardboard envelopes not terribly expensive, I
think its harder to actually get the discs into the hands of the right people. Even when an
influential person has the disc there is little certainty that she will spend an hour or more
installing and configuring the product so that she can evaluate it. Microsoft has two programs
that help to overcome these issues.
TechNet Virtual Hard Disks (VHDs) are pre-configured virtual machines that you can download
and launch within Virtual PC or Hyper-V, it’s a great way to familiarize yourself with
Microsoft’s latest software solutions. VHDs are available for many Microsoft products, the
drawback is that the downloads are very large. It takes me a day or two to download multi-
gigabyte files.

TechNet Virtual Labs is even easier to use, you merely select a scenario and then access the
servers remotely using your web browser. What happens in the background intrigues me. I was
never involved in designing or building any of the virtual labs so I do not know precisely what
the underlying architecture is but its easy to deduce the major elements. Try one out and you will
see what I mean. After you sign up for your first lab you are prompted to install an ActiveX
control, then you wait a few minutes while your lab is being built. I suspect that a pre-configured
VHD is copied for your use, and then launched on a server running Hyper-V, and that you
connect to your own personal virtual machine using an ActiveX RDP client that has been
customized for TechNet. When you finish your VHD is deleted, no matter how badly you hack
up your lab it will not impact other people accessing the site. Take a look at both of these
programs for yourself:

 TechNet Virtual Hard Disks.

 TechNet Virtual Labs.

Configure Terminal Services Gateway

The TS Gateway is designed single-purpose Secure Socket Layer (SSL) Virtual Private Network
(VPN) that can be used to grant remote users secure access to TS servers. Users connect using
whatever RDC client they prefer, the RDP traffic is encapsulated in Hypertext Transport
Protocol (HTTP), which is protected by SSL/Transport Layer Security (TLS). TS Gateways
increase security by ensuring clients only have access to the specific TS servers they require for
their job without the need to configure full VPN connectivity. A certificate must be installed on
the TS Gateway Server, it is used for SSL/TLS, you probably have a self-signed certificate
installed in your practice lab, in a production environment you should use a certificate generated
by a Certificate Authority (CA) trusted by the computers that will be used to access the TS
Gateway, otherwise users will encounter browser warnings about a certificate which cannot be
validated. The TS Gateway server must belong to an Active Directory domain if you configure
authorization policies that require users or client computers to be domain members, or if you are
deploying a load-balanced server farm.

The next step is to configure authorization policies. There are two kinds of policies, you need to
configure at least one of each: Terminal Services connection authentication policies (TS CAP)
and Terminal Services resource authentication policies (TS RAP). A TS CAP specifies who can
connect to the TS Gateway server. You can further restrict inbound connections by other criteria
such as whether their computer is a member of an internal Active Directory domain or whether
to allow resource redirection for Plug and Play devices. A TS RAP defines what internal
resources the users can access through the TS Gateway server. To create these policies open TS
Gateway Manager and click on the server in the navigation tree, then do the following:
 1. Expand the TS Gateway server in the navigation tree, expand the Policies folder, right-click the
Connection Authorization Policies folder, select Create New Policy, then click Custom.
2. On the General tab, enter a name for the policy and ensure that Enable this policy is selected.
3. Click the Requirements tab, enable the desired authentication method, then click Add Group to
select which groups of users will be allowed to connect, as shown in figure 3. Optionally, you can
also specify which groups of computers are allowed.

Figure 3: Defining the TS CAP Requirements.

4. Click the Device Redirection tab, you can specify whether or not device redirection is allowed.
Keep in mind the fact that the enforcement of this policy occurs on the client computer so do
not think of it as a robust security setting, a determined user may be able to bypass it.
5. Click OK to finish creating the TS CAP.
6. Right-click the Resource Authorization Policies folder, select Create New Policy, then click
Custom.
 7. On the General tab, enter a name for the policy, ensure that Enable this policy is selected, and
enter a description if desired.
8. Click the User Groups tab to define which users can connect.
9. Click the Computer tab to specify the internal computers that can connect to. There are three
options:
a. Enter the name of a domain security group that includes the computer accounts for the
appropriate TS servers.
b. Create a local group and add the names of the computers as shown in figure 4.

Figure 4: Configuring a New TS Gateway Computer Group.

c. Allow users to connect to any internal resource.

10. If the TS servers are configured to use custom TCP ports click the Allowed Port tabs to specify
the port numbers. Click OK to finish creating the TS RAP.

There are a few other configurable settings for TS Gateway servers. Right-click the server in the
navigation tree and select Properties to view them. You can limit the number of simultaneous
connections, select a different SSL certificate, configure a TS gateway server farm, and make
other changes using the server’s properties dialog box. To view active connections select the
Monitoring folder in the navigation tree.

Using TS Gateway with Internet Security and Acceleration Server

Internet Security and Acceleration Server (ISA) can enhance the security for a server running the
TS Gateway role service because it can inspect incoming traffic before forwarding it. In this
configuration the ISA server is configured as an SSL bridge, that is, ISA handles the
establishment and maintenance of the SSL tunnel so that it can view the decrypted network
packets. In this architecture the clients establish and SSL connection with the ISA server, the
ISA server decrypts and inspects the traffic, then the ISA server forwards acceptable traffic to the
TS Gateway. The connection between the ISA server and the TS Gateway can run over HTTP,
for greater security implement SSL between these servers too.

To implement SSL bridging export the SSL certificate from the TS Gateway server, copy it to
the ISA Server, then install the certificate on the ISA Server. Create a web publishing rule on the
ISA server to enable access to the TS Gateway server. When creating the web publishing rule
you can specify whether to use HTTPS-HTTP bridging or HTTPS-HTTPS bridging. Export and
importing the certificate is a little complicated, to do so perform the following:

1.      On the TS Gateway server, open the Microsoft Management Console by clicking Start and
then entering mmc.

2.      You must manually add the Certificates snap-in, click File, then click Add/Remove Snap-
in.

3.      Select Certificates and click Add.

4.      Specify Computer account and click Next.

5.      Select the local computer and click Finish.

6.      In the navigation tree, expand Certificates (Local Computer), expand Personal, then click
Certificates.

7.      Right-click the TS Gateway certificate, select All Tasks, and click Export. If you are unsure
which certificate to export view their properties to determine which meets the TS Gateway
requirements.

8.      Complete the wizard to export the certificate.

9.      Copy the certificate to the ISA server.

10.  On the ISA server, repeat steps 1 through 6.

11.  Right-click on Personal, select All Tasks, and click Import.

12.  Use the wizard to specify the copied file, when prompted to specify the certificate store
select Automatically select the certificate store based on the type of certificate.

13.  Finish the wizard to complete the importation process.

Tip: remember that the default file extension for certificates is .cer, but if the private key is also
exported the default extension is .pfx instead.

Configure Terminal Services Load Balancing

TS Session Broker provides load balancing for TS servers, that is, clients are evenly distributed
across the farm of servers to minimize the risk of any becoming overloaded. It maintains session
state data including which user is associated with each session ID and the name of the server
servicing the session. This means that users can automatically be reconnected to their existing TS
session should their connection terminate unexpectedly.

The architecture is straightforward: some load balancing method is implemented independently

of TS, two or more TS servers, and the TS Session Broker server. Round Robin DNS is the
simplest load balancing method, the DNS record that points to the TS server farm has a list of
addresses, one for each server in the farm. The DNS server responds to queries by cycling
through the addresses sequentially. After the client retrieves the address from the DNS server it
establishes an connection to the initial TS server. The initial TS server queries the TS Session
Broker server to determine which TS server the client will use. The initial server then redirects
the client to use the assigned server. The client then establishes a full TS session to the assigned
server and that server informs the TS Session Broker of its new client connection. This concept
is illustrated in figure 5.
Figure 5: Using Round Robin DNS with TS Session Broker.

When using DNS round robin to distribute connections then you must configure DNS records for
each server in the farm. However, any load-balancing method can be used, including the
Network Load Balancing Service (NLBS) available with Windows Server 2008. For information
about NLBS see Deploying Servers. Microsoft published a detailed guide for load balancing
terminal services with NLBS called Network Load Balancing Step-by-Step Guide: Configuring
Network Load Balancing with Terminal Services.

The process of installing and configuring the TS server farm and the TS Session Broker is as
follows:

1. Install and configure the TS server role, desired role services, and user applications on each TS
server in the farm.
2. Install the TS Session Broker role service on another server.
3. On the TS Session Broker server, add each TS server in the farm to the local Session Directory
Computers group.
a. Open Computer Management, expand System Tools in the navigation tree, then
expand Local Users and Groups, and select the Groups folder.
b. Double-click the Session Directory Computers group in the details pane.
c. Click Add, then click Object Types, enable the Computers checkbox and click OK, as
shown in figure 6.
Figure 6: Enabling the Selection of Computer Accounts.

4. Configure each TS server in the farm using Terminal Services Configuration:

a. Double-click Member of farm in TS Session Broker and select the TS Session Broker tab.
b. Specifying the name or IP address of the TS Session Broker server under TS Session
Broker server name or IP address.
c. Specify the name of the farm under Farm name in TS Session Broker.
d. Enable Participate in Session Broker Load-Balancing.
e. Adjust weight if desired by changing the value of Relative weight of this server in the
farm.
f. Specify the IP address to be used for reconnection and click OK, as shown in figure 7.
Figure 7: Configuring TS Session Broker Settings.

Most TS Session Broker settings can be configured through group policy at the following
location: Computer Configuration\Administrative Templates\Windows Components\Terminal
Services\TS Session Broker. Group policy can simplify configuring multiple TS Session Broker
servers with identical settings. The two settings that cannot be configured via group policy are
the IP addresses to be used for reconnection and the relative weight of each server. For more
information about using group policy see Creating and Maintaining Active Directory Objects.

Does Microsoft Innovate?

Some pundits sharply criticize Microsoft for not innovating but rather growing its technology
portfolio through acquisitions and copying other firm’s ideas. In my personal opinion, while it is
true that many Microsoft technologies became Microsoft’s after the company purchased the firm
or licensed one of their products the company is hardly unique in this regard. It is also true that
when another company opens a new market sometimes Microsoft will begin to compete
aggressively with them a year or two later, but again, numerous companies do this. I think the
Terminal Services technology is an interesting case that brings together several examples relating
to these accusations.
Formed in 1989, Citrix Systems licensed source code for Windows NT 3.51in 1992, upon which
they built WinFrame. Released in 1995, WinFrame was their most successful product thus far.
The firm was struggling to survive when Microsoft invested significantly in the company and
licensed the technology that became Windows NT 4.0 Terminal Server Edition, which was
released in 1997. Microsoft purchased another company, T.share, for the RDP used for
communication between TS servers and clients. Citrix has done quite well over the past 20 years
by continuing to maintain a mutually beneficial relationship with Microsoft. Citrix retained the
right to extend upon Microsoft’s TS-based products.

So far you see examples of Microsoft not developing their own technology from the ground up,
but the story is far from complete. Microsoft went on to improve the core technology and build
many other solutions based upon it. Since acquiring the technology Microsoft has added load
balancing, RemoteApp applications, TS Gateway, and sophisticated device redirection.
Microsoft has also created whole new solutions based on TS such as Remote Assistance where
users share their desktop with another remote user who can help resolve problems. The switch
user capability in Windows XP, Windows Vista, and Windows Server 2008 is another TS-based
feature. Windows Meeting Space is also based on TS.

Configure Terminal Services Licensing

The purpose of the TS Licensing role service is to help track client access licenses (CALs). It
ensures that your organization does not violate its purchase agreements by having more clients
connect to the TS servers than the number of licenses purchased. When a client connects the TS
server checks to see if a CAL is required, if one is needed the TS server will request it from the
TS Licensing server. If one is available the license server will issue it. Two simultaneous Remote
Desktop sessions are allowed for remote administration without requiring CALs or a license
server. CALs can be tracked by either user or machine. There is also a 120 grace period that
allows unlimited client connectivity without requiring activation of the license server or
installation of CALs.

Before the license server will begin issuing licenses you must activate it. Open TS Licensing
Manager, right-click on the server in the navigation tree, and select Activate Server to launch
the Activate Server Wizard. The wizard provides three activation methods. The simplest is
Automatic connection; the license server requires ongoing Internet connectivity to use this
method. The Web Browser method allows you to activate from another computer that has
Internet connectivity, the license server does not require such connectivity in this case. The
telephone method allows you do activate by contacting a Microsoft customer service
representative. Once activated you can install CALs but you must validate them using one of
these three methods. To install CALs right-click on the TS Licensing server in the navigation
pane, select Install Licenses, and complete the wizard.
You configure the licensing mode on each TS server using Terminal Services Configuration. To
do so double-click on Terminal Services licensing mode in the details pane and then select Per
Device or Per User. You can also specify a license server for the TS server to use, or allow it to
automatically discover a license server, as shown in figure 8. If these choices are dimmed its
because they have been configured via group policy. Note that per-user CAL tracking is only
supported when the servers and users are members of an Active Directory domain. Also, the
license server must be a member of the Terminal Server License Servers group in Active
Directory, it should have been added to the group automatically during installation of the role
service.

Figure 8: Configuring Licensing for Terminal Services.

You can use the Licensing Diagnosis tool to troubleshoot licensing issues. To launch the tool
open Terminal Services Configuration and click on Licensing Diagnosis in the navigation
tree. Information about the server’s configuration and license status will appear in the details
pane. Consider my test server for example, as you can see in figure 9 I face two problems, the
license server is not activated and no CALs are available.

Figure 9: Diagnosing Licensing Issues.

Each CAL is valid for between 52 and 89 days, the number of days is determined randomly
when the CAL is issued. When a CAL is due to expire in 7 days the TS server will attempt to
renew it, again, for between 52 and 89 days. If it cannot connect to the license server it will
attempt to renew the CAL each time the client logs on. When a CAL expires it is returned to the
pool of available licenses. This helps the license server to automatically recover Per Device
CALs that are lost when the device is no longer in use or when its operating system is reinstalled.
If the license server itself is lost then you should try to recover it using the most recent backup. If
no backup is available then you must reinstall the server, reactivate it, and contact the license
clearinghouse to have them issue replacement CALs.

Configure and Monitor Terminal Services

Resources
You may want to limit how much memory or CPU time a particular application can consume on
any server that needs to support many users who access several different applications. This is
particularly important on TS servers sustaining large numbers of simultaneous user sessions, a
single user who consumes a large portion of system resources will negatively impact all of the
other users. There is a powerful tool for controlling resource usage in Windows Server 2008:
Windows System Resource Manager (WSRM) As noted in Maintaining the Active Directory
Environment, Windows System Resource Manager is an optional feature of Windows Server
2008. Take a quick look at the Using Windows System Resource Manager section in that chapter
to install the tool on the TS server in your practice lab.

WSRM uses resource-allocation policies to control the use of computer resources. WSRM
includes two policies designed for Terminal Services.

 Equal_Per_User – Processes are clustered by user, each cluster has access to the same
proportion of system resources regardless of how many applications are running.
 Equal_Per_Session – Processes are clustered by TS sessions, each session has access to the
same proportion of system resources.

To implement the Equal_Per_Session resource-allocation policy do the following:

1. Open Windows System Resource Manager from the Administrative Tools folder and specify
This Computer when prompted to connect to a computer.
2. Expand the Resource Allocation Policies node in the navigation tree.
3. Right-click Equal_Per_Session and click Set as Managing Policy.
4. If a confirmation dialog box appears click OK.
After configuring WSRM policies you should observe performance of the TS server to verify
that the impact is positive. Click on the Resource Monitor node in the navigation tree to get
started. Click the Add Counters button (the green plus symbol) and select the Terminal
Services Session counters from the list of available counters, click Add, then click OK, as
shown in figure 10. These include dozens of counters, you can hide some from the graph by
deselecting their checkbox under the Show column. Other performance counters that will help
you assess the performance impact of the resource allocation policy from a higher level are those
related to processor and memory utilization. You can review the Using Reliability and
Performance Monitor section in Maintaining the Active Directory Environment to refresh your
memory on how to use performance counters.

Figure 10: Adding Terminal Services Session Performance Counters.

Configure Terminal Services Client

Connections
There are many client configuration settings available, broadly speaking, they are managed in
three different locations. Most client settings can be configured on the client computers. Most
client settings can also be managed in Active Directory using group policy, a few additional
settings can be configured on the user account objects. Some settings can be managed on the TS
servers.
Configuring Client Settings on the Client

There are three ways for clients to connect to TS servers. Remote Desktop Connection (RDC)
is the primary way. There are several methods for invoking RDC including clicking the shortcut
from the Start menu, double-clicking a customized .RDP file, or by entering mstsc.exe at a
command prompt. You can also connect using the ActiveX-based client as discussed earlier in
the chapter. The third way is to use the Remote Desktops MMC snap-in. This snap-in is
included with Windows Server 2008, you can install it on Windows Vista by downloading and
installing the Microsoft Remote Server Administration Tools for Windows Vista. This snap-in is
designed for administrators who have to connect to numerous servers using the RDC but don’t
want to clutter their desktop with shortcuts for each. You right-click on the Remote Desktops
node in the navigation tree and select Add new connection to add a server to the list of servers
in the navigation tree. You right-click on any of the servers and select Connect to open a TS
session in the right-hand pane, as shown in figure 11.
Figure 11: Using the Remote Desktops Snap-In.

After creating a connection in Remote Desktops you can right-click on it and select Properties
to customize it. There are three tabs for saving logon credentials, specifying the desktop size,
configuring drive redirection and making a few other changes. There are additional
customization options available when you use RDC, click Options to see the tabs that grant
access to all of them, as shown in figure 12.

Figure 12: Customizing the Remote Desktop Connection.

You can improve performance by reducing the screen size and lowering the color depth on the
Display tab. You can further optimize performance by disabling the graphical features available
on the Experience tab. The Local Resources tab is where you configure whether to bring sound
from the remote computer to the client, how to handle Windows key combinations, and what
local resources on the client to make available on the server. This last option is particularly
important because it has security implications. If you connect to a server under the control of
someone who wants to do you harm and you choose to make your local disk drives available on
the remote server that malicious person may be able to figure out how to access files on your
local computer without your permission. It would be a complicated attack, so its not an issue in
most situations, however it may be a feature you wish to disable in high security environments.
The Programs tab is where you configure the name and working directory for an application to
launch after connecting to the TS server. You can configure server authentication and TS
gateway settings on the Advanced tab.

Configuring Client Settings in Active Directory

There are two places to configure client settings in Active Directory. You can modify a couple of
settings by editing the properties of each user account object. To do so open Active Directory
Users and Computers, navigate to the desired container, right-click on the account you wish to
modify and select Properties. You can configure the path to the TS user profile and the TS home
folder, as shown in figure 13.

Figure 13: Configuring the Terminal Services Profile for an Account.

Note: you can also configure the profile and home folder paths for local accounts by editing the
properties of the account in the Local Users and Groups snap-in.
When managing large numbers of users group policy is a more convenient way to configure all
of these settings. These settings are available in the group policy editor at Computer
Configuration\Administrative Templates\Windows Components\Terminal Services. For
example, below this location, navigate to Terminal Server\Device and Resource Redirection
to disable drive redirection and to manage other related settings. Note well that some of the
settings are server options while others are client options, read their descriptions carefully to
ensure that you understand which settings apply to clients. User specific settings for Terminal
Services can be found at User Configuration\Administrative Templates\Windows
Components\Terminal Services.
Configuring Client Settings on the Server

To configure client settings on the TS server open Terminal Services Configuration, right-click
on RDP-tcp below Connections in the details pane, select Properties, and click the Client
Settings tab, as shown in figure 14. You can configure device redirection and color depth,
however these settings are enforced on the client. Although they normally take precedence over
the settings configured on the client a determined user with administrative privileges may be able
to bypass them. Of course, only the members of the information technology staff who actually
need administrative privileges have them, right? Right?

Figure 14: Configuring Client Settings on the TS Server.

Important: When users connect to a default installation of a server via Terminal Services some
aspects of the desktop and applications available will look different. To ensure a smoother
experience for end users install the Desktop Experience feature using Server Manager. This will
install applications and features they will be familiar with from Windows Vista such as Windows
Media Player and Windows Calender.
 Configure Terminal Services Server Options
To configure TS server settings open Terminal Services Configuration, right-click on RDP-tcp
below Connections in the details pane, and select Properties. You configure encryption and
authentication on the General tab, the most secure values are to use SSL (TLS 1.0) for the
security layer with and encryption level of FIPS Compliant and Network Level Authentication
enabled, as shown in figure 15. However, using these values will cause problems with older
versions of RDC.

Figure 15: Configuring Terminal Services Encryption.

Use the Log on Settings tab to have all incoming connections log on with the same account,
however use this setting with caution as it increases the risk of an unauthorized person accessing
the server. You can configure session limits on the Sessions tab so that disconnected sessions,
idle, or active sessions are terminated after the specified time. This can help ensure that memory
is not wasted on sessions that are not being used. The Environment tab is used to specify a
program to be launched automatically for each user when they connect. You can configure
whether remote control is allowed, and if so whether the user must grant permission on the
Remote Control tab. Remote control is very useful when troubleshooting or training users,
however a malicious administrator could use this feature to surreptitiously observe another
employee working with sensitive data. This concern should be low on your list of priorities
though, if you give administrative privileges to people who are not trustworthy then you have
much bigger problems then to worry about than TS remote control. You can define which
network adapters will listen for RDP connection requests and limit the number of simultaneous
connections on the Network Adapter tab.

There are two ways to specify which users are able to log into the TS server via RDP: by
configuring the groups and accounts on the Security tab of this dialog box, as shown in figure 16,
or by adjusting membership in the Remote Desktop Users group. The second method is the
preferred one because it is simpler and less likely to lead to misconfiguration.

Figure 16: Viewing RDP Permissions.

When managing large numbers of servers group policy is a more convenient way to configure
these settings. You can find them in the group policy editor at Computer
Configuration\Administrative Templates\Windows Components\Terminal Services.
Remember that some of the settings are server options while others are client options, read their
descriptions carefully to ensure that you understand which settings apply to servers.

Managing Active Sessions

To view and manage active sessions open Terminal Services Manager. Right-click on the
Terminal Services Manager node in the navigation tree to add more servers to the management
list and to organize them into custom groups. Select a server in the navigation tree to view the
active sessions. There are three tabs in the details pane, make sure the Users tab is selected. You
can right-click on a session to disconnect it, take remote control, reset it, send the user a pop-up
message, and force the user to log off. Click the Sessions tab to see the list of sessions and their
current status, right-click on any to perform the same tasks noted for users. The Processes tab
displays all of the running processes on the TS server including which account was used to
execute it. It is similar to Task Manager, but you can also view processes on remote terminal
servers. Right-click on a process and select End Process to forcibly terminate it.

Summary
In my opinion, Terminal Services is one of the best features in Windows Server 2008. It is
awesome for managing remote servers, especially for systems administrators who are not
comfortable using the command prompt and writing scripts. Its also a great way to centralize
management of end user applications. Regarding exam preparation, this technology makes up a
considerable proportion of the content and its important that you have a solid understanding of
how to implement, manage, and troubleshoot it.