Learn how to implement Terminal Services on Windows Server 2003.
One of the Windows server features that has evolved the most over the years is Terminal Services. Originally released as an add-on feature for Windows NT, Terminal Services has become an integral feature of Windows Server 2003. Here's how you can implement Terminal Servers on Windows Server 2003.
What does Terminal Services do?
In case you aren’t familiar with Terminal Services, it is a mechanism that allows applications to run on the server rather than on the user’s workstations. Terminal Services simply send screen images to the users, and the user’s machines in turn send keystrokes and mouse movements back to the server. In a way, Terminal Services work a lot like a graphical version of a mainframe / dumb terminal setup.
Just as a dumb terminal has no computing power of its own, Terminal Services allow clients to run applications that they might otherwise not have the hardware to support. In many ways too, Terminal Services is considered to be more secure than a traditional computing environment because all applications are running on a centrally controlled server.
What's new in Windows Server 2003
Although Terminal Services offer a lot of benefits, they are just now starting to become really practical in my opinion. The Windows 2000 version of Terminal Services worked really well, but required the terminal server to have a tremendous amount of resources. Each session really consumed a lot of network bandwidth.
Among the Terminal Server enhancements in Windows Server 2003 is the use of the Remote Desktop Protocol (RDP). If RDP sounds familiar that’s because it’s the same protocol used by Windows XP for the Remote Assistance feature. The RDP protocol is designed to compress data related to Terminal Service sessions. This allows Terminal Service sessions to be more responsive to the users and to use a lot less bandwidth. In fact, although I have never tried it personally, I have a friend who swears that accessing his Terminal Server over a 56 Kbps modem is almost as good as accessing the server through a local Ethernet connection.
There are some other improvements as well. Unlike the Windows 2000 version of Terminal Services, the Windows 2003 version now supports transmitting sound. The Windows 2003 version also supports greater color depth than its predecessors.
As if all of these new features weren’t enough, there is at least one other new feature worth mentioning. Terminal Services now have the Windows XP Remote Assistance feature built into them. For example, imagine that you got a phone call from a user who was having trouble locating a specific document on the network. You could go through the whole "Click here, Click there" routine over the phone or you could take control of the user’s session from the comfort of your own desk, open the document for the user, and then give control of the session back to the user.
Installing Terminal Services
If you have worked with the Windows 2000 Terminal Services much then you are probably expecting me to tell you to open the Control Panel, Click Add/Remove Programs, and then go to the Windows components section of the Add/Remove Programs dialog box. I’m not going to though because Terminal Services is installed by default in Windows Server 2003.
At first this was surprising to me because of Microsoft’s commitment to make Windows Server 2003 as secure as possible right out of the box. Having Terminal Services running by default just seemed like a security risk if an organization was not planning on using them. However, just because Terminal Services is installed, it doesn’t mean that they are active. It’s up to you to activate Terminal Services.
When I say that you have to activate Terminal Services, I’m not talking about activation in the sense of the way that you have to activate Windows. Activating Terminal Services involves assigning a role to the server. To do so, select the Manage Your Server command from the server’s Administrative Tools menu. When you do, you will see the Manage Your Server dialog box. As you can see in Figure A, this dialog box displays the roles that are currently assigned to your server. Take a quick look at the list of currently assigned roles to make sure that the Terminal Server role isn’t already assigned.
|The Manage Your Server dialog box displays a list of the roles that are presently assigned to the server.|
Assuming that the Terminal Server role hasn’t been assigned yet, click the Add or Remove a Role link. When you do, Windows will launch the Configure Your Server Wizard. The wizard’s initial screen displays a lot of information, but it basically just tells you to make sure that the server is connected to the network and to the Internet (if appropriate). Click Next and you will see a list of the roles that can be assigned to the server, as shown in Figure B. Select the Terminal Server role and click Next.
|Select the Terminal Server role and click Next.|
At this point, you will see a summary screen that simply says Install Terminal Server. Click Next and you will see a warning message indicating that the installation process requires the server to reboot. Close any open applications and click OK. Windows will now install the necessary files and reboot the server. The entire process only takes a minute or two.
When the server reboots, it will have two open dialog boxes. One of these dialog boxes is a help window displaying all sorts of information of configuring Terminal Services. The other dialog box is the continuation of the Configure your Server wizard. This dialog box informs you that you must have a Terminal Server License Server somewhere on your network. You have a 120 day grace period during which you may use unlicensed connections. After that though, only licensed connections will be accepted. Click Finish to acknowledge this message and you will be returned to the Manage Your Server dialog box. Go ahead and close the Manage Your Server dialog box because you won’t need it again for this operation.
Terminal Services is now active, but before anyone can use them, they must be granted permission to do so. This is another area in which Windows Server 2003 has been greatly improved over Windows 2000. In a Windows 2000 Active Directory environment, if you wanted to grant permissions to a thousand users, you would have to grant permission to each user individually or else write a script to complete the operation for you. If you aren’t really into scripting then this made for a very long and boring process.
Windows Server 2003 works differently though. The Active Directory Users And Computers console allows you to select as many users as you would like. Once the users have been selected, you can right click on one of the selected users and then select the Properties command from the resulting shortcut menu. You are now free to assign Terminal Service access permissions. Whatever permissions you assign will be applied to all selected users.
When editing a user’s Terminal Service configuration, there are three tabs on the user’s properties sheet that you will need to look at. The first tat is Terminal Services Profile path. This tab has three primary elements. First and most important, there is a check box at the bottom of the tab that must be selected before the user will be allowed to log into Terminal Services, as shown in Figure C.
|Terminal Services Profile tab allows you to grant a user access to Terminal Services.|
The next thing that I recommend setting is the path to the user’s home directory. You have the option of either mapping a drive letter to a network share point, or entering a path to a local path. Keep in mind though that in a terminal server environment, a local path refers to a folder on the server itself.
The other option on Terminal Services Profile tab is the one that needs the most explaining. This is an option to enter the profile path. As you probably know, a user’s profile stores things like their desktop display settings, drive mappings, and screen saver selection. Terminal Services Profile tab gives you the option of either not entering a profile at all or of pointing Windows to the user’s existing roaming or mandatory profile.
If you already use roaming profiles, this one might seem like a no brainer. Before you start entering the path to the user’s profiles though, stop and think about what you are really doing. There are some settings within a user’s profile that work great locally, but that are not suitable for use with Terminal Services. The classic example is the screen saver setting. On a local machine it is no big deal if a user’s profile tells the machine to run a screen saver. If that same profile were used on a Terminal Server though, the screen saver would actually run on the server and screen refreshes would be transmitted to the user’s desktop. Although screen savers are good for security, this is a terrible waste of server resources. If you must use a screen saver within a Terminal Service profile, then use the blank screen saver.
Even if your users don’t even use screen savers, pointing Terminal Services to an existing roaming profile is still a bad idea. Think about how a roaming profile works. The profile loads when the user logs in. When the user logs out, any changes that they have made to the profile are saved as the profile is closed.
Now, imagine that a roaming profile is called by Terminal Services. A user would come into the office in the morning and power up their machine. After doing so, they would log into Windows at which point the profile would be loaded. Next they sign into Terminal Services. Upon logging in, Terminal Services also open a copy of the user’s profile. Now, suppose that the user were to make a change to the profile while working in a Terminal Service session.
Upon signing out of Terminal Services, Terminal Services would try to save the changes, but wouldn’t be able to because the user still has the profile open at the User level. Any changes made to the profile through Terminal Services is therefore lost. As you can see, it’s best to make Terminal Services point to either a mandatory profile or to no profile at all.
The next tab that you need to know about is the Sessions tab. It’s easy to think of a session in terms of being either online or offline. However, Terminal Services don’t work this way. Terminal Services recognize three different connection states. A connection is said to be either Connected, Disconnected, or Terminated (sometimes the term Reset is used interchangeably with Terminated).
An Active session is exactly what it sounds like; a session that is connected and actively in use. A Terminated session is also what it sounds like; a session that has been ended. The term Disconnected session is a little misleading though. As you know, all applications within a Terminal Server environment run on the server. When a session is disconnected, it simply means that the client workstation has broken off communications with the server. Any applications tat the user had open are still open because they are running on the server, not on the workstation.
It’s the entire concept of a disconnected session that makes the Sessions tab, shown in Figure D, important. The Sessions tab allows you to control what happens to disconnected sessions. As you can see in the figure, the first option on this tab is when to end a disconnected session.
The default value is Never. It’s OK to never end a disconnected session as long as the same basic group of people use Terminal Services each day. The problem comes into play if you have consultants occasionally come in and do work for you. Imagine that you have given a consultant a temporary login. The consultant logs in, spends one day working on the system and then disconnects without logging out. That consultant’s session will be Active until the day that you reboot the server. The disconnected session isn’t really hurting anything, but it is consuming server resources and software licenses.
The next two options on this page are the Active Session Limit and the Idle Session Limit options. The Active Session limit allows you to control how long someone is allowed to be Actively using Terminal Services. The default value allows users to run active sessions indefinitely. The idle sessions limit allows you to configure how long an Active session is allowed to sit idle before being terminated.
Beneath these fields are options that allow you to control what happens when your session limits are reached. You can choose to either disconnect the session or terminate the session. If you choose to disconnect the session then you must also choose whether a user is allowed to reconnect the session from any computer or only from the computer that the session was originally running on.
The last tab involved in Terminal Service configuration is the Remote Control tab, shown in Figure E. Just as the name implies, you use this tab to configure the remote control settings for Terminal Services. By default, a user is not allowed to remotely control another user’s session (the exception is the Administrator). If you did want for a user to have remote control capabilities select the Enable Remote Control check box.
|The Sessions tab allows you to control what happens to disconnected sessions.|
Another check box on this tab is the Require User’s Permission check box. If this check box is selected then when the user tries to remotely control another user’s session, the user will be notified of the attempt and must approve the connection or else the connection is not allowed. This makes for a great security feature because it prevents anyone from watching a user’s session without their knowledge or consent.
The final portion of the Remote Control tab is the Level of Control section. You can grant a user permission to watch other users, or permission to actually take control of a session. Generally, you would use the View The User’s Session option only if you were trying to train a new employee or if you were trying to police user’s use of the system. Generally if you wanted to help users work through problems you would use the Interact With The Session option.