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.

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.

Users need the Remote Control right to shadow each other's sessions.
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.

Sysinternal's Process Explorer
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.

Adding a KeepAliveEnable Registry key can help control bandwidth by terminating idle sessions.
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.

comments powered by Disqus

Reader Comments:

Sat, Apr 5, 2008 Mr.Deng China P R

hi, I'm very interested in your article,especially the 7: keep yourself alive.
But I wonder, Is these registry modify should be done on server machine or client machine? I made the modify on client machine, but it doesn't work. about 10 minutes without any operation, and my session was disconneted.
thank you very much! I hope you'll help me.

Mon, Mar 26, 2007 Terry NZ

While I wouldn't image as frequently as nightly, I think the suggestion that this would be a recipe for disaster doesnt need to be the case.
To maintain consistency I'm a strong believer that your installation and patching regime should all be part of a scripted build. If its a robust setup then there should be no reason why you cant re-deploy a server at will without any dramas.
However, good article, keep them coming.

Sat, Mar 24, 2007 Jason Anonymous

RE: Tip 2:

As far as I know, the latest version of UPHCLEAN is 1.5d, not 1.5e.

Fri, Mar 23, 2007 Anonymous Anonymous

Why would you rather reimage your servers daily or weekly rather than just lock them down with GPO? If you're users have access to move system files around then I think you need to look at your build.

It doesn't take hours to lock down a desktop (certainly less than scripting a rebuild process) and there's no need to change NTFS or registry.

Wed, Mar 21, 2007 Anonymous Anonymous

the more TIPs the better , please...
Keep um coming!!

Wed, Mar 21, 2007 Anonymous Anonymous

Re-image your servers daily. Are you kidding me? That's a recipe for disaster from a software distribution and patching perspective.

Tue, Mar 20, 2007 Anonymous Anonymous

Some very good insights

Wed, Nov 23, 2005 Anonymous Anonymous

why some citrix bits?

Mon, Oct 31, 2005 Patrick Rouse California

Nice article Greg, these are all great tips from the field. Here are some more:

8. Don't install 3rd party printer drivers on a terminal server. If you can't get the functionality you need from mapping to a built-in driver via user defined inf file (or fallback driver in 2003 SP1), purchase an EMF or PDF based printing product whcih supports all printers.

9. If you don't have an EMF or PDF based printing program, don't waste your time trying to get a LIDIL printer to work (they don't work over TS without one of these programs).

10. Don't ever elevate users to Power Users or Administrators to get a program to work. Use regmon & filemon from sysinternals.com to determine which elements of the file system or registry a user needs write permissions.

11. Do use GPO Loopback Policy Processing to lock down your terminal servers wo locking down users when they're not logged onto TS.

12. Never install untested software on your terminal servers, just because it's a new update, or because someone asked you to. Test in a lab environment, pilot, then deploy to the masses.

13. Make sure you have a good backup just in case all of the prep work you did in number 12 still wasn't sufficient. Image based backups are the best, and you should always have a stable build to revert to so you don't have to spend hours troubleshooting a production server. You should always be prepared with a fallback plan.

14. Don't say I don't have the resources to have a lab environment to do testing. Anyone can afford one or two cheap hand-me-down computers to test with. You don't need $5000 server-class hardware to create a test lab.

15. If using Server 2000, locking down the file system is an absolute necessity when building a new server. 2000's default NTFS Permissions are NOT suitable for Terminal Server, as everyone has Full Control Permissions of the system drive.

Patrick Rouse
Microsoft MVP - Terminal Server
http:www.sessioncomputing.com

Wed, Sep 28, 2005 Dan UK

Nice article. Gonna get me that Process Explorer, and I've implemented the Keep Alive registry edit too. Thanks.

Tue, Aug 30, 2005 Eric Maine

Great article - fixed one of my issues

Wed, Jun 15, 2005 Sergio Blum Brazil

Very good article! Indeed, Citrix Consulting Team use all os this stuff... It's all best practice.

Fri, Apr 22, 2005 Anonymous California

Good stuff. I will definitely be using the Process Explorer very soon.

Mon, Apr 18, 2005 kashif Pakistan

It is very good article.

Fri, Apr 8, 2005 RRS Anonymous

Good Article keep them coming

Fri, Apr 1, 2005 JV NJ

Good article but much of it is pre-empted by WS2003 especially with SP1. My biggest peave with TS is letting users run IE without restrictions on adding sites.

TS is not tuned as a files server and shouldn't be hence files should be on a real fileserver fo both safety and performance BUT - if it is a small TS and a big iron platfrom then you can do it if you don't minfd the administrative headache. I prefer them separated.

WS2003 SP1 eleiminates the need for UPHClean - it's built in.

Don't forget CPROFILE - schedule it weekly if you users don't keep to much crap in lists. Most don't.

Tighten security as much as you can and then some.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.