Accessing the TS
By
now, as you had to connect to your terminal server to make sure it was running
and to get familiar with Process Monitor as per above, I am sure you know how to
connect to the TS.
But as
there are a couple of ways to do that, I think it is a good idea to explain what
each client is, what they do and how to use them.
Full client
By
full client I mean the full, Win32 client that comes with Windows XP or Windows
Vista (the famous MSTSC.exe one). Of course there are different versions of such
client (for RDP5.0, RDP5.2, RDP6.0 and now RDP6.1).
As
you already know, to access a terminal server using this client is a very simple
process. Just launch MSTSC (go to
Start | Run | MSTSC
and press enter) and enter the IP address or FQDN of your TS. If you click on
‘Options’ all the available options (drive mapping, printers, etc)
will appear.
Fig.
34Remote Desktop
Client
There
are also some command-line options
(like /console to
connect to the ‘console’ on your 2003 box). Just type mstsc /? to
see all the available options.
Fig.
35MSTSC command
line options
This
is the client in use on Windows XP Embedded thin clients and on Windows Server
2003 as well. Of
course they may have
different build numbers (i.e. 5.2.3790.1830, etc) but we usually refer to them
as the ‘Win32’ client.
Web client
A
couple months after releasing Windows 2000 back in February, 2000, Microsoft
released an ActiveX version of the RDP client. For the first time users were
able to connect to a simple web page and from there, with the ActiveX client
automatically loaded on their machines, connect to a terminal server anywhere on
their networks or on the Internet (to see how popular this became simply do a
search on Google for “allinurl:tsweb/default.htm”; the results are
impressive!).
Fig.
36TSWEB default
web page
Although
this is indeed a neat way to access your terminal servers, this also mislead
people to thinking they could connect to their terminal servers through a single
port (http:80 or https:443); in reality, tsweb was simply a mechanism to deliver
the RDP client through a web browser and to provide a front end for the client
options (i.e. username, server name, resolution, etc) but the actual RDP
connection was still going through port TCP 3389 so at the end two ports were
required and as of today, this is still the case with Windows Server
2003.
Windows Server 2008 does
have a mechanism to use a single port for RDP access, over https.
ι
Again, remember that tsweb will not
give you RDP over a single port like 80 or 443; even though your users may be
able to access this port through their web browser, they still need to be able
to reach the terminal servers through port TCP 3389. And of course I do not need
to mention this page is NOT compatible with Linux and/or Mac OS X as it requires
an ActiveX control (Windows only) to be loaded...
- Download
the package listed above and copy it to your IIS server.
- Double
click tswebsetup.exe to start the installation.
- Click
‘Yes’ to install the tsweb
package.
Fig.
37
Installing
TSWEB
- Click
‘Yes’ to accept the license
agreement.
Fig.
38
TSWEB
license agreement
- Select
the folder on your IIS server where you want TSWEB to be installed. I would
recommend another folder as you could see on Google the amount of companies
using the default page and exposing their infrastructure details on the
internet!
Fig.
39
TSWEB
default installation folder
- Once
the installation finishes it will ask if you want to read the release
notes.
Fig.
40
TSWEB
release notes
- If
you followed all the steps above you should see this
window.
Fig.
41
Successful
installation
Now
all you need to do is to point your users to your web server and they will see
the default TSWEB webpage. If they are connecting over the internet, remember
you will need to make sure your TS can be reached (port TCP 3389 open) and that
they use the TS FQDN or external IP address to connect!
Other clients
Of
course the next question is ‘what if my clients do not run Windows? Can
they still connect to my terminal servers?’. The answer for this question
is ‘Yes, they
can’.The only
non-Windows platform supported directly by Microsoft is Mac OS X. A native OS X
client (universal binary!) does exist and is available for download on the
Microsoft website.You can
get it here:http://www.microsoft.com/mac/downloads.mspxFor
Linux the most common client is RDesktop, a free, open source alternative. As
RDP was a proprietary protocol until March, 2008, all non-official RDP clients
lacked support for some sort of feature (i.e. proper serial port redirection)
and RDesktop was one of these. The same is valid for some Java implementations
out there. Therefore if your most important requirement is a fully compatible
RDP client, as of today your only alternative is to use the full Win32
one.But this did not
prevent other companies to develop RDP clients and replacements for the desktop
OS with a built-in RDP client, basically turning PCs into Thin Clients with a
very light OS that can be loaded on the machine over the network (using PXE
boot) or even from USB drives or CDs. One of the most impressive solutions out
there is the 2X ThinClientServer. It not only allows you to boot PCs with its
own streamlined OS but can handle real thin clients as well. All this from a
nice web based
console.ι
Note:
I am not mentioning the 2X solution because they sponsored this guide. I have
actually tried many similar solutions and years ago had my own distribution to
do the same. But none of them, including mine, had all the centralized
management features on top of a pretty web console. Add to that the fact they
have a free version (the unsupported PXES one) and I still think there is no
other solution like this on the market as of today. I know this may change in
the future, like with any other software solution out there. But as of today
they are ‘The
Solution’.You can check
them out at http://www.2x.com.It
is worth mentioning that when using thin clients (small computer like devices
with little local processing power and designed to be used as a
‘dumb’ terminal, connected all the time to a terminal server) you
must pay extra attention on your requirements. As the OS on these devices vary
(i.e. Windows XP Embedded, Windows CE, Linux, etc) the RDP client on these will
not be the same across the board; this means certain features may not be fully
supported on the device depending on the OS it is running. If your main
concern/requirement is 100% compatibility with the latest RDP version out there
your best bet is to use devices running Windows XP Embedded.