Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

What are the advantages of using a (Windows) Terminal Server and thin clients instead of using a normal Server and full clients?

So far I've only really used normal servers and clients, but now customers ask about terminal Server, and I'd like to know pro's and con's of using them instead of an "old-fashioned" client-server network.

Some things I can guess: easier administration (don't need to install/update office/stuff on 20 computers but only on the server).
Easier backup (no need to backup client computers).
And I'd guess it would be hard (impossible) to connect and use local (like USB) hardware with Terminal Server?

What else are the reasons for or against switching to Terminal Server?

share|improve this question
    
Please edit your post to mark it 'community wiki'. –  ThatGraemeGuy May 6 '10 at 13:13
    
K, done - so many great answers, I got no idea which one to pick. Great, thanks a lot folks! –  Sam May 25 '10 at 8:36
add comment

7 Answers

up vote 3 down vote accepted

We used both environments (we're a public school system), and when I started here we were running several terminal servers for teachers and students, and now we're fat clients and role-specific servers (no terminal servers for users).

Pros- centralized management. When you have two or three people overseeing a huge number of users with a significant portion online at any time, it is fantastic to be able to install a "necessary" desktop shortcut or install a program a few times and have it instantly available to all the users rather than rely on automated package installers or AD to hopefully roll out the change to desktops. I know people talk about how wonderful AD is at installing MSI's, or how XYZ can solve this installation issue, but we've had plenty of cases where for one reason or another the installation failed or didn't work properly and we had to clean up the mess by hand or just install the @#$ thing manually at each workstation. Not. Fun.

"Instant" troubleshooting. We were able to check a user's session easily and quickly when a call came in. Yes, remote desktop software can do this (and we use it). But on the terminal servers, you have a small pool of machines, not a desktop that was tweaked or altered with XYZ programs that you didn't know where changed by another tech or it was changed and the records are lost or never kept. Tight adherence to policies and record keeping can do this. Reality is, at least in public school systems I know of, this isn't followed very often.

You have fewer machines to back up and monitor. Desktops are easily swapped and can be run on the cheap. All you need is a thin client or a system capable of running terminal service client; hardly need a gig of ram and a hundred gig hard drive for that. We were running PII and PIII systems with barely enough RAM to run Windows 98 comfortably as clients; students were sticking gum in them and jamming them with papers and when the time came that the client died, we just swapped it out with another cheap spare, no special software or custom configuration necessary.

Monitoring users was simpler. Not really big brother monitoring (unless you wanted to take it to extreme), but when users were suspected of violating the AUP or their sessions were showing unusual activity, it was easy to pop in and check what was happening (running an exe you're not supposed to? Why is the web filter showing odd activity for your session here? Sometimes it was just a call from a teacher saying Johnny was acting suspicious and minimizing something while in class)

Upgrade a server and a large number of users benefit, all at once!

Cons? You have twenty users on a system. System reboots, dies, hardware issue,...twenty users, kicked offline, instantly. And users don't understand terminals to begin with. They don't care why something's weird. They just know something isn't working. One switch goes wonky or one server goes wonky and you've taken out a large number of users.

Load balancing creates issues. If user is on machine A, and machine A (or network connection to A) goes down, they may log in and get machine B. Their session was still on A, and they wonder why they now don't have their Word document they were working on, but it's in their home directory and it's showing up as "open" or "locked." Whoops.

Resource hogging. Can be handled with quota management on resources, but we had cases in early versions (Win2k term services) where a user would log in, load animated maps from weather sites, and leave for a class without logging out. Half an hour later the machine is CRAWWWWWLING. Memory was leaked from the @#% flash movie animation, hogging RAM and leaving us with no choice but to kill the session.

Some programs do NOT like terminal services. Hopefully it improved, but a big one was Office. You had to install it with a special "terminal services mode", or the installation would act really weird or not function properly. Other programs just acted strange. Windows was NOT designed to act as a multiuser platform; it was meant to support multiple users asynchronously at a workstation (this workstation allows any number of users to use it at different times), unlike UNIX workstations that have their design roots in timeshare systems (a workstation you're sitting at can be running with another ten or fifteen users using SSH or remote X terms and you'd barely be aware of it unless they were hogging a resource). This could easily get to be a technoreligious argument, but the fact is that because of the "organic growth" in Windows' architecture, there are many developers that take shortcuts and older software simply acts...strange...under Windows Term services. I think that issue has definitely improved as MS has started forcing people to adhere to design recommendations.

Need to reboot a server or perform maintenance? Again, you have one machine going down, it takes everyone out.

You need a reliable network infrastructure to work. The users need a good path from desktop to the server. If the client machine died, a switch, a cable, a server,...their computer platform dies. With fat clients, you could potentially have a server failure and users could still do something else (i.e., mail server is down, but users can still work from their home directories or local files and just be irked that the mail server is down, not the whole system).

Most businesses wouldn't have to worry about it, but if you have cheap shovelware (think kid's "edutainment" titles), it doesn't take much to bring even a powerful server to its knees.

Printer drivers acted strange at times. Interaction among software increases the chance of "glitches". Especially with terminal servers...they always seemed more sensitive to it. But maybe I'm being paranoid. Remember one server affecting everyone? Well, one bad software install can cause headaches for everyone...and bit rot was a constant cause for edginess as drivers were updated or configuration changes were made.

There is a layer of complexity added. You brought up USB, maybe things like sound, etc...again, this I think was improved since our time. But it still means another place where things can go wrong, and it's not like sitting down at a fat client to troubleshoot. You're trying to redirect stuff over the network on a server that is dealing with connections from another dozen users. Weird stuff happens. In IT, complexity is bad to intentionally introduce.

Overall terminal services are cheaper, despite the CALs necessary for licensing. Your systems scattered around are cheaper, you can manage more users with fewer people, and you invest in your servers and network infrastructure, not necessarily giving the CEO a $2,000 machine for doing his email. But they're only cheaper if you're running in an environment that is suited for terminal services.

If your users are running Office apps, browsing the web, email...basic stuff...probably worth looking into. If they're running specialized stuff, test the @#$% out of it first, making sure it's compatible, that there aren't file locking or sharing issues or even display issues (print drivers were horrible at times if you did something that managed to get "printer monitors" running and they got confused to which display was actually being viewed, but it's not just those applications that hated the idea of multiuser hacks).

We had to move because over time we were getting more and more people that HAD to have something they wanted installed but other people didn't, and for licensing it could only be used by a small group of people. Or the software was made with Macromedia Director (ugh) and didn't "quite" work right (refresh was "off" with graphics, animations were choppy...). Or we had people running software that was just bloated and bogged down servers. Or we had people that had to use CD's for a presentation or material and they couldn't access them via the terminals (again, may have improved). Eventually we were putting in special workstations for certain tasks (log in once to run Photoshop, use the terminal shortcut to get to Office...) and finally it was too much of a burden to dual-support having labs that ran XYZ and terminals to support ABC. We had too many diverse needs.

That's my experience with them. They're great for certain tasks. You need to evaluate your client's needs and whether they're appropriate for that situation. If not, stick with fat clients.

share|improve this answer
    
+1. Wow, great answer. A few points: With NT4 and W2K TS and Office you had to install Office (and many other applications) with a transform file. That hasn't been the case since W2K3. The only caveat is that you have to put the server in "install" mode (either from the command line or from Add Remove Programs) when installing Office, or any other program. W2K3 SP2 TS introduced the fallback printer driver and W2K8 TS introduced EasyPrint and these have reduced the number of printing problems related to printer drivers. –  joeqwerty May 6 '10 at 11:51
    
The install mode and such were a pain because unless you're thoroughly familiar with these procedures, it was easy to fubar an install. And sometimes it let us install things without error, only it didn't work right because it wasn't in the right mode. And since terminals were considered edge cases, most software didn't warn you of this stuff, so it wasn't intuitive (again, unless you were neck-deep in a terminal environment and not from a fat client background). It was a definite pain at times. –  Bart Silverstrim May 6 '10 at 12:08
1  
I will say that when it worked, though, terminals were fantastic. We're understaffed with a huge number of users and they were a huge help. The problems came with the number of edge cases that slowly grew until managing the terminals became illogical. –  Bart Silverstrim May 6 '10 at 12:09
1  
True, managing a TS environment (especially a large one) is a different skill set than managing a typical client\server environment. There are plenty of nuances to TS environments that take time to understand and work through. Again, great answer on your part. –  joeqwerty May 6 '10 at 12:49
    
@Joeqwerty-thanks. TS is a great tool, but definitely niche skills. It's also one of those things that people can develop myopia for...have a hammer, everything's a nail? TS can solve anything! Um...no. :-) –  Bart Silverstrim May 6 '10 at 13:41
add comment

PRO's: Too many to mention but Chopper3 made a good start, although I don't think it takes any less skill to manage a TS environment. In fact many times I think it takes more skill. I manage a 20 TS server farm and I don't see myself as being less skilled than my colleagues that don't manage TS environments.

Con's: Printers can be sketchy. Not all applications can be licensed and\or installed on a TS. Unless the TS is adequately secured it can get hosed by the users. A misbehaving application affects all users instead of just one user.

share|improve this answer
add comment

Pros - tight control of the environment, generally easier to have good security, system consistency for users, generally easier to do code updates. Cons - generally lower performance from a user standpoint, often tied into one vendor's systems (i.e Windows).

There's nothing you can benefit from with a TS system that can't be acheieved by good sysadmins in a non-TS environment but it can be easier for a less skilled/experienced sysadmins to manage a TS system.

share|improve this answer
    
There are some cases where a TS system is better than not - think of a client application that performs best (or at all) if it's local to the single central backend DB, and no easy way to write a web interface or other light front-end. And you have thousands of small offices that need this application. TS/Citrix solves that handily. Aha - I see Oskar made the same point below. –  mfinni May 6 '10 at 18:46
add comment

I am by no mean an expert on TS, but here are a few points comming from my experience :

  • USB can be connected locally and used on the server (at least with Citrix)
  • management of the server has to be much more rigourous than management of private workstations (single point of failure : if one user can screw the server, nobody can work anymore)

Where I work now, we use TS for some simple applications that are only rarely used by everybody. Or for testing (we have access to old versions of Windows / IE).

I do know a few companies which have vitrualized all workstations, but it seems to work much better when you have simple requirements.

On the cost side, the equation is not as straightforward as it might seem. You still have to pay licences for the clients, and even if you now only have one server to manage and not a bunch of workstations, the job is more difficult and require more qualifications...

share|improve this answer
add comment

Pros - It works like centralized server. Easily manageable, for eg: if you need to update anti-virus, you can easily update it at one location with admin control, and it will effect other users. Effective admin Control, can easily monitor users, you can know which user is taking more resource according to which you can manage the services.

Cons - If server is down, users suffers. Hangs up the entire server when any of user on server is using high server resource thus effect other users. Have to continuously monitor the services. Takes a good amount of network space if thin-server is accessed among other servers.

For Printers- If once accessed with admin control, it then allows other users to access the required printer.

share|improve this answer
add comment

One advantaged others have not mentioned so far is that having a Terminal Server environment makes it pretty easy to setup remote access. Particularly with the Windows 2008 Remote Desktop Gateway. Setting up users to be able to work from home or a remote location is pretty easy.

share|improve this answer
add comment

Many good pros and cons, but I'm missing performance on the pro-side. Yes, perhaps controversial but I know performance was the first factor for us when we went with terminal servers many years ago.

If you have applications that aren't written for high-latency client-server situations - running it on a regular fat client in a remote office against a central server may result in severe performance issues.

One example would be trying to run an Access database form from a file share that's not locally replicated. Switching to a central terminal server environment in that case will boost application performance as it is then running on a central very high-performance terminal server, with a high-capacity and low-latency connection to the application server or resource. Many older line-of-business applications built with similar technology will respond much quicker if the client-side part is running close to the server-side.

And as long as the load isn't sustained and ruining the experience for other users, a number of older applications can actually respond a lot faster to the end-users not only due to lower latency to resources but because there's room for more burst performance in a high-speed server (obviously screen refresh may not be fluid, but fluid animation and quick result on say a customer search form are two very different things). Almost like Chopper said, going TS is sometimes an easy way to fix old stuff. There are other ways to do it like replicating file resources, using branch cache functionality and switching to web applications - or even siloing individual applications which would gain from this into terminal servers, serving them on fat clients as a seamless application.

Serving terminal server sessions to users on the road can also provide performance boosts. Trying to use a laptop and VPN while on a train using mobile broadband to access a shared Access form or line-of-business client-server-app with always-online-requirement on a central server will most likely be infuriatingly slow and unreliable. Replace it with a terminal session and it will probably be very zippy as long as the connection doesn't die completely. And if it does die, the session state will be preserved when resuming the connection (as long as the set parameters for auto-logoff aren't met) and the user can continue his or her work where it was left.

The world is moving on from systems where this is true but, not all companies are...

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.