In-Depth

7 Terminal Services Tips

Terminal Services is a lot like poker—anyone can play, but it takes smarts and strategy to play well. These seven tips will make you a shark.

• By Greg Shields
• April 01, 2005

I went to a casino recently to learn how to play poker with my buddy John. That night, after a few drinks and a lot of card games, I realized there's a connection between poker and Terminal Services. "Connection?" you might be asking yourself. "What sort of connection?"

Well, you can play the Terminal Services (TS) game for years and think you have it mastered. Until you get some tips from the pros, however, you'll never learn how to play really well. With that in mind, consider me your TS card shark. Take a look through these seven tips for deploying and administering TS and work them into your game. When you're done, don't forget to tip the dealer.

1. RAID 5 Is Not Your Friend
Administrators have always taken full advantage of their servers' hot-swap capabilities. With hot-swap, RAID 5, and an extra drive bay, you never had to worry about running out of space.

However, in today's environments with Storage Area Networks (SANs) and the separation of application servers from the data layer, you just don't need huge amounts of storage on your TS servers. You should already have a policy in place to inform your users that no data is safe on TS servers. They should store all data on their home or shared data drives.

With a solid policy like that in place, you'll no longer need RAID 5's expandability. By moving your hot-swap servers to a RAID 1 configuration, you'll realize a much greater benefit—the RAID 1 "Undo."

Say, for example, you're about to apply some driver updates to your TS servers. You've never applied these updates before and you don't really have a lab in which you can test them. Like most of us in this situation, the only option you have is to back up the system prior to the installation, deploy the updates and hope for the best. Your back-out option is a costly and lengthy restore.

With hot-swappable RAID 1, available on nearly all server-class machines, you can automatically create a quick "undo" before you apply that patch. Just pull one of the drives.

Hot-swappable RAID cards are designed to automatically fail the drive as it's pulled, leaving you with a broken mirror, but a system that still functions. There's nothing anywhere that says you can't operate with a broken mirror for long enough to ensure that your driver updates install correctly. Once you're satisfied everything is working, just pop the pulled drive back in and re-establish the mirror.

You can also use this method for economical server cloning—no downtime required. Simply pull one of the drives from the mirror on the source system and drop it into the same slot on an identical target system. Once the system boots, drop in a second drive and let them re-synchronize. In less than an hour, you've got a replica of your original server without ever powering down.

2. Cure the Long Goodbye
If you've been working with TS, you've dealt with logoff delay problems. Lengthy logons and logoffs have been the bane of the TS administrator. To help with this, just last year Microsoft quietly released the User Profile Cleanup Service (UPHClean). This tool, now in version 1.5e, reduces logoff time and virtually eliminates profile problems in the Event Log like the aggravating "Event ID 1000: Userenv" error.

Long logoff problems are typically associated with poorly written or non-TS-aware applications that don't close Registry resources properly upon logoff. Because those resources are left open, the logoff doesn't properly unload the user's Registry hive. This problem is the main cause for those Event ID 1000 errors. It will eventually cause logon errors that can prevent the user from logging in.

UPHClean can run as an application or a service. For your TS servers, it's convenient to install the service and let it run continuously. The tool will initially scan for open Registry resources and force them closed. Then it will continue running and fixing in the background. You can find UPHClean on the Microsoft Web site. Look for Knowledge Base article 837115.

3. Isolate Those Nasty Apps
If you administer a large TS farm using Citrix MetaFrame, you may have dealt with application conflicts as the number of apps per server increase. Adding non-32-bit applications or poorly-written applications exacerbates the problem. If you've added MetaFrame's application-publishing feature to your TS servers, you can leverage that capability to centralize those nasty apps onto their own servers. The term "application silo" is increasingly being used to describe this type of application isolation.

The concept is easiest to explain with an example. Let's say your farm includes four applications. Three of those—Microsoft Word, Excel, and PowerPoint—are needed by every user in the company. The other, a poorly-written financial application with bad memory leaks, is needed by only a few people. You have five Citrix servers that serve these applications, and each of the apps are installed on all five servers.

In our example, if your finance application's memory leak causes a server to fail, you've affected everyone on that server. By using an application silo, you install only the finance application onto one of your servers. All users still get their Office apps via any of the remaining four Citrix servers. The users who need the nasty finance application access it via a Citrix Published Application on the silo. When the memory leak affects the silo, it won't bring down the rest of your company.

4. We Can Rebuild It; We Have the Technology
Earlier, we talked about streamlining disk space and implementing a no-storage policy on your TS servers. Doing this frees you to implement a scheduled-rebuild policy. Remember that TS servers are like a big workstation used by lots of people. As they do on their own workstations, users move files around and change settings, not realizing they're important to the system. Without resorting to a costly third-party tool to secure against meddling users, you're faced with countless hours tweaking NTFS permissions, the Registry and Group Policy to keep your users honest and your TS servers stable. Plus, any of those hundreds of tweaks could cause a blue screen down the line. Many of them will change every time you apply a patch or add a new application.

Make your life easier. Consider laying down a best effort on security, then establishing a scheduled-rebuild policy. By re-imaging your servers every night or every week, you gain the comfort of knowing they remain at a stable baseline. You've eliminated the added stress and effort of maintaining a highly secure but inflexible configuration.

Imaging software like Symantec's Ghost Enterprise and HP's Altiris Server have come a long way in using the PXE boot capabilities onboard nearly all server-class equipment to schedule imaging operations after hours. You'll also save money on backups, because your standard images automatically become your nightly backups.

5. The Shadow Knows
MetaFrame has long touted its ability to let users shadow each other's sessions using the Citrix Shadow Taskbar. What many people don't know is that it can grant that same capability to users when using TS.

To let your users shadow each other, you'll first need to change a setting in Administrative Tools (see Figure 1 below):

Click on the RDP-Tcp connection inside the TS Configuration window.

1. From the Permissions tab, click Advanced.
2. Select the Users permission entry and choose View/Edit.
3. In the resulting window, grant the Users group the Remote Control right.

Shadowing in TS isn't as user-friendly as with the Citrix Shadow Taskbar. To discover the users logged on to the same server you're using, type query user at a command prompt. You'll receive each logged in user's username, session name and ID, status, and their idle time and login time. Armed with the session ID of the user you want to shadow, type shadow into the command prompt. The user will get a dialog box requesting permission to let you shadow their session. If they accept, you're in. To stop the session, type Control-*.

If the user is on another TS server, type query user to list the users on that remote TS server. To shadow the remote user, type shadow /server: .

If you're particularly handy with scripting, you can write code to make this process easier for your users. You can expose many useful TS hooks through Windows Management Instrumentation (WMI) using VBScript.

Figure 1. Users need the Remote Control right to shadow each other's sessions. (Click image to view larger version.)

6. Trade up from Task Manager
With TS, you're often called to troubleshoot problems that occur when users clobber each other's resources. Using Windows Task Manager for this kind of troubleshooting is challenging. Task Manager shows you running processes and who is using them, but it isn't useful if the problem requires deeper information about why the process is behaving badly.

Mark Russinovich and his team at Sysinternals have written a tool called Process Explorer, shown in Figure 2, below. You can download this freeware tool from www.sysinternals.com. Process Explorer should be a requirement for every TS administrator, as it provides comprehensive vision into the files, DLLs, threads and Registry keys being touched by every process on your server.

Newly spawned processes flash green in the monitor and flash red when terminated. This makes the tool very easy for identifying runaway processes within user sessions and their root cause. Process Explorer also helps you locate files locked by another user. When a user or system process doesn't properly release a locked file, any attempt to delete or move the file will result in the dreaded "sharing violation" error. Using this tool, you can view and kill the processes locking your open files.

Figure 2. Sysinternal's Process Explorer provides a much more comprehensive look at process usage than Task Manager. (Click image to view larger version.)

7. Keep Yourself Alive
The Remote Desktop Protocol (RDP) TS uses is, by design, a very thin protocol. Users have the tendency to log in to a TS server, do some work, then leave their desk for extended periods of time. On WAN links with high latency, TCP/IP will see these inactive connections as dead and eventually terminate the socket. During these idle times, you can configure TCP Keep Alives to prevent the connection from staying idle for too long by sending a "heartbeat" packet to the server every so often.

To enable TCP Keep Alives, open the Registry on your TS servers and navigate to HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\Terminal Server. Then create a new key called KeepAliveEnable with a DWORD value of 1. Figure 3 shows an example.

Figure 3. Adding a KeepAliveEnable Registry key can help control bandwidth by terminating idle sessions. (Click image to view larger version.)

Although the default settings are usually sufficient, you can also set the Keep Alive Time and Keep Alive Interval values. The Keep Alive Interval determines the time between "heartbeat" packets, while the Keep Alive Time determines how long the server will respond to "heartbeat" packets from an idle connection before severing the connection.

To modify these parameters, navigate to HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and look for the KeepAliveInterval and KeepAliveTime keys. Configured in milliseconds, the default for KeepAliveInterval is set to 1,000, or one second, while the default for KeepAliveTime is set to 7,200,000, or two hours.

Serious poker players—the ones who win the big money—spend years perfecting their craft. If you put in the same commitment to learning Terminal Services, you'll get your own big payoff in a stable, efficient TS environment that will allow you and your users get a lot more work done remotely.