Terminal Services: From A to
Z
About this Guide
After
working with Microsoft Terminal Services (and pretty much all the add-ons
available), answering thousands of questions on the subject at the Microsoft
public newsgroups and Experts-Exchange (where I go by the tsmvp alias), myself
and 2X decided to move ahead and publish this small, simple yet very valuable
guide about Terminal
Services.
As the name
implies, the idea is to cover pretty much everything you need to know to
properly deploy a terminal services based environment. Although there may be
different ways to do certain things I will cover in this guide, everything here
is based on my own experience in the field and all solutions described have been
tested and in production for many years for many of my own customers. Again,
they may not be the best or the ones by the book. But they do work and they are
stable indeed.
Introduction
As
you can see I do not assume any previous knowledge of Terminal Services;
therefore we must explain a little bit about Terminal Services, how it works and
why it may help you.
Before
you guys go ahead and email me, bashing this guide, I just want to clarify a
couple points. First of all this guide does not intend to be an in-depth book
about Terminal Services and how to do everything related to it; secondly it is
not meant to be 100% technical, written for people with years of experience with
Terminal Services.
This
guide is for everyone out there considering a Terminal Services deployment, but
with no experience, or very little knowledge on the topic. It will lay down the
foundations to successfully deploy a terminal services environment, giving you a
solid understanding on how all this works which will help you immensely as you
progress with your Terminal Services skills.
What is it?
Terminal
Services, as it is today, is an old technology wrapped in some new, fancy
wrapping paper.
If you are
old enough, or if you have read at some stage how computing environments were
back in the 60s, you probably heard the word ‘Mainframe’ and/or
‘Dumb Terminals’ (those almost like computers, with a green screen
terminal and a keyboard). The idea behind them was quite simple: one big box
(the mainframe) was responsible for running all the applications and processing
all the data at a central location. In order to run applications, users would
connect to the mainframe using the so-called ‘dumb terminals’. These
had no local processing power at all; they would simply send the keyboard
entries back to the mainframe and the mainframe would send back the screen
updates. So although users could ‘see’ their text based applications
on their screen, everything was actually happening at the
mainframe.
Fig
1
Mainframes and
dumb terminals
Fast
forward to today’s environments and this whole ‘centralized
computing environment’, sometimes referred to as ‘Server Based
Computing’, is back in full swing but of course with a revamped interface.
Exactly like in the 60s, today’s server based computing environments
centralizes all the applications and is responsible for all the required
processing power. As you can see the main difference is simply the interface.
Everything today relies on a GUI and a mouse so the old ‘mainframe’
idea just got updated to do the same old tricks but using today’s
interfaces. Terminal Services is simply a Windows Server based component
(available on Windows 2000 Server and up) that delivers a unique
‘desktop-like’ environment to multiple users at the same time, all
running off a single server (or multiple servers for high availability
purposes). The same old tricks but with a couple updates.
Fig
2
Today’s
Server Based Computing GUI
Server
based computing takes care of the processing required to run applications and
the applications themselves, allowing users to access these resources from
pretty much any device with little processing power and no applications
installed locally. Terminal Services is just the ‘Microsoft Windows’
way of doing that, giving users the familiar look and feel they are used
to.
Why TS?
The
main question many people ask when they start researching about Terminal
Services is ‘Why TS?’. There are many reasons why a Terminal
Services (when I say ‘Terminal Services’ I mean server based
computing in general – that idea of a centralized location that runs your
applications) solution is the way to go and we will cover some of these
here.
As with any other
technology or solution, it is not perfect and more than that, not recommended
for everything. Based on my experience with it (over 13 years now!) I can
definitely say I can find a reason (or a need) for Terminal Services on every
single company out there. The key thing is to determine where TS would work well
and actually help your company.
Advantages
of using Terminal Services::
- - Centralized.
When using TS, applications are all installed on the terminal servers and not on
every single PC in your company. This means if you have 5 terminal servers
(using current hardware and well behaved applications, you can probably have 75
users per server, simultaneously) and you are deploying something like SAP
using it, you have only 5 machines to upgrade when a new SAP release comes out,
instead of upgrading 375 user PCs. Much easier to manage 5 boxes than
375.
- - Performance.
Many applications out there work just great when you use them on your LAN. With
VPNs becoming more and more popular, users can now connect to the office and
work from home. Once you try to run that application from your PC at home, over
a much slower link (remember, at the office you are connected probably at
100MBits or 1GBit and at home you usually have a 2-7MBits high speed DSL or
Cable), performance will probably suck. If you try the same application over
Terminal Services it will be pretty much the same experience as if you were
sitting at the office. Remember that TS sends you the screen updates only and
not the whole data the application is actually using. That data is transferred
between the TS itself and your application back
end.
- - Extended
lifecycle. As your applications now run
on the Terminal Servers, the client machine does not need to be upgraded often
(as all the hard work is done on the TS side), greatly reducing your costs on
hardware upgrades.
Of
course not all applications will work well under Terminal Services. Some good
examples are graphic intensive applications (AutoCAD, Google Earth, 3D Studio,
etc), resource intensive ones (MathLab, etc) or applications that require some
local hardware to be present (i.e. applications that must deal with USB
peripherals that require drivers to be installed on the local PC).
But
again, I am certain if you look around your company you will find a place for
Terminal Services. What about that old application you were considering spending
huge amounts of money to port to a web version? You can probably have it running
on TS and provide access to it from anywhere in the world! No changes
required!
The lesson to be
learned here is simple: TS is not for everything and not for everyone. But it
can be an excellent tool and problem solver for many companies out there. It is
up to you to determine where it can help you.
