Powering Up Terminal Services with Service Pack 1by Mitch Tulloch,author of Windows Server Hacks
Terminal Services is a powerful feature of Windows Server 2003 that lets users access Windows-based programs across an enterprise. Using Terminal Services, users can run the latest apps even if their computers are underpowered and running old versions of Windows. Terminal Services also provides users with access to Windows programs from non-Windows computers, thin-client hardware, and small devices such as PDAs running Windows CE. Terminal Services also makes life easier for admins, since deploying and managing network apps can be done centrally on a Terminal Server (TS) instead of in distributed fashion across the network.
Of course, Terminal Services has been around since before Windows 2000 days, but there are compelling reasons for upgrading Windows 2000 Terminal Servers to Windows Server 2003. These reasons include improved management capability by using Group Policy and Windows Management Instrumentation (WMI), an improved remoting protocol (RDP 5.2, which supersedes Windows XP's version RDP 5.1), and increased scalability by using the new Session Directory feature together with the Network Load Balancing (NLB) component.
Now that Service Pack 1 for Windows Server 2003 has been released, however, there are even more reasons you'll want to upgrade Windows 2000 Terminal Servers to Windows Server 2003. That's because Windows Server 2003 Service Pack 1 includes several useful enhancements to Terminal Services. Let's look at these.
Before Service Pack 1, if a Remote Desktop Connection (RDC) client needed to print to a locally connected printer but the Terminal Server didn't have the printer driver installed for that type of printer, the user was out of luck. With SP1, however, you can now enable a Group Policy setting called Terminal Server Fallback Printer Driver Behavior (see Figure 1), which can provide a workaround for the situation until you can install the proper driver on your Terminal Server.
Figure 1. Policy setting for fallback printing
Let's look at this new policy in more detail by opening its properties (Figure 2):
Figure 2. Details of fallback printing policy
When the fallback printing policy is enabled, you have four choices of how to configure it. The simplest approach, if you know TS users have PCL-supported HP printers, is to select the "Default to PCL if one is not found" setting. In that case, if the RDC client can't find a suitable printer driver on the TS, it will use a PCL driver compatible with the popular HP DeskJet 500 series printers. This should work pretty well in most situations. Other options for this policy include defaulting to a PostScript printer driver, offering a choice between PCL and PostScript, or doing nothing (in which case the user won't be able to print to the local print device). Note that all of this is moot if you've previously enabled the "Do not allow client printer redirection" policy for Terminal Servers, as in that case all local printing functionality is disabled by default.
While RDP 5.2 does provide for the encryption of TS sessions, it doesn't provide for the authentication of the TS by the RDC client. With SP1, however, you can now install an X.509 digital certificate on the TS so that RDC clients can use Transport Layer Security 1.0 (basically another name for SSL) for secure authentication with the server. That way the client can validate the identity of the server so it can be sure it's connected to the correct server instead of a rogue server that's somehow been connected to the network. For details on how to set this up, see this KB article on TechNet.
Starting Programs upon Connection
Windows Server 2003 Terminal Services previously included a policy called "Start a program on connection," which administrators could enable to prevent users from accessing anything other than the specified program they need to do their work (see Figure 3). The idea was that by enabling this policy, a user would log on to the TS using RDC, and, instead of being presented with a Start menu and the Windows desktop, he would see only the window for the program the administrator had specified. Then, after he finished his work and tried to close this program window, the result would be that his TS session was also terminated. This is a great way to lock down TS so that users can run only one specified program at a time if that's all they really need to get their work done.
Figure 3. Policy for starting a program on connection
The trouble was that the original implementation of this policy worked only if the TS was also a domain controller. SP1 fixes this policy so that it can now be applied on TS member servers using Group Policy, or even on stand-alone TS servers by configuring the Local Group Policy Object (LGPO) on those servers.
Finally, SP1 includes three new policies for managing how licensing works in a Terminal Services environment. These new policies are:
- Use the specified Terminal Server license servers--Lets you specify which TS licensing server a TS should use to register its licenses (see Figure 4). This can be useful in very large enterprise deployments of TS servers and clients.
- Set the Terminal Server licensing mode--Lets you override server- or client-based licensing configurations to help you standardize how TS licensing should be configured.
- Show Tooltips for licensing problems on Terminal Server--This policy saves time so you don't have to double-click on TS licenses to check their status or view when they expire. Instead you only have to point at them and read the tooltip that pops up.
Figure 4. New TS licensing policies
If you're running Windows Server 2003 Terminal Servers in your environment, you'll likely find these new TS enhancements in SP1 useful in both easing the administrative burden of managing TS and in ensuring a smooth experience for TS users. And if you're still running Windows 2000 Terminal Servers on your network, you now have some more reasons to upgrade to Windows Server 2003.
Return to the Windows DevCenter.