What is Terminal Server?

Terminal Server (TS) is an add-on to NT 4 Server and Win2K Server that has been around for quite some time.  However, with the release of Win2K Server, TS has shown its real value.  Essentially, TS allows multiple users to come into a central server and run desktop (or LAN)  applications as if they were working on their own computers.  With the expansion of reliable high speed internet access, TS provides businesses the opportunity to have a centralized database application(s) with real time information at their fingertips.  While the same can be argued for a web enabled application, TS allows companies the flexibility to expand usage of Windows-compliant LAN applications already in-use, perhaps offer employees the option of telecommuting, etc., without reinventing the wheel by rebuilding their application for web use.

The desktop for TS users can be modified to fit a variety of users: for example, some users may come in to run a single app, others may need access to other applications or programs, and your administrators need access to everything.  Additionally, you can set TS to run a particular application after logon, so your data entry personnel could logon and be presented with this single app.

What is required for Terminal Services?

Reliable, high-speed internet access is an absolute.  I’ve run TS applications across connections ranging from a 56K dial-up to a cable modem to T-1’s.  While the 56K connect allowed me to run the application, the latter two allow the application to be presented nearly as fast as if on a LAN.  We recommend a 128K connect at the client as the absolute minimum acceptable connection.  The server should have at least a 384K connect.  These connection recommendations are entirely dependant upon the reliability of the connection.  Guaranteed bandwidth must be assured by the ISP’s involved.  We have one client with their server connected to a 128K ISDN line and, while the server performs admirably, some of the clients have unreliable connections with ISP networks that are overburdened, which only frustrates the end-users.

Your server should be dedicated to TS and only TS.  If you approach a TS environment with the attitude that you can run everything and the kitchen sink on a single server, you are doomed to failure.  Similarly, you may need more than one server, depending on the number of clients coming in.  Generally, we do not recommend more than 10-12 concurrent users on a single TS server.

The server you choose should be fairly hefty.  We generally recommend nothing smaller than a dual-Pentium class with 523 meg RAM.  Keep in mind this is a starting point.  Win2K likes RAM even more so than NT, so plan accordingly.  The demands your application places on the O/S may drive additional requirements.

If you are planning on upgrading an NT 4 server to Win2K or if you are purchasing/building a Win2K server, be sure to do your homework.  In one instance, we were assured the server and all installed components/hardware were Win2K compliant (a requirement we generally stipulate in our contracts), only to find out the motherboard did not support Advanced Configuration and Power Interface (ACPI).  To make matters worse, we had already upgraded the O/S, installed the necessary tools, configured TS, reconfigured the clients on the LAN, run our normal regimen of tests, etc., to have the server crash horribly in the third day of full-up operations.  The only clue we had to something being fundamentally wrong was the appearance of kernel processes occupying 2%-8% of the CPU’s ticks.  To make a very long story short, we had to completely reinstall the O/S without ACPI support and go through the entire configuration process again.  Fortunately, we had set up a “temporary” server just in case something like this happened.  Needless to say, the effort required to overcome this “oversight” was significant.

Client Operating Systems and Client Access Licenses

Win2K Professional comes with a Client Access License (CAL) for Terminal Services Client.  You can also purchase CAL’s for Windows 98/ME and NT 4.0.  We generally recommend the clients run Win2K Pro if possible, although we have seen acceptable performance with clients running Win 98.

Okay, I can connect, but can I print locally?

Absolutely!!  However (there’s always a however isn’t there), to print locally, your default printer must either be attached to or mapped to your LPT1 port.  A system administrator must “install” the appropriate printer as a local printer on the TS.  One practice we have adopted is to then delete the printer as this helps keep the printers folder clean.  When a user logs on and requires this particular driver, a connection is made and TS maps to this printer at the client computer.  One other stipulation is that during printing, the client must remain connected until the print job finishes.  Print speed is generally acceptable with report size, connection speed, printer speed, etc., all having a role in the printing process.

dB2K & Terminal Server

dB2K and Terminal Server work together like they were made for each other.  Using the advanced features of dB2K such as DEO, and just like your LAN apps, updates are a breeze.  Just drop the new object files in the appropriate folder.  No need to rebuild the executable.  No need to post changes to all of the client computers.

We generally install a dB2K app on a TS just as if it were on a workstation.  The program files are in one folder, the object files are in another folder, the BDE is installed and necessary aliases are established. There are some things you need to consider if, for example, your users require access to local tables for printing, etc.  When creating the profile for your TS users, just point the local drive setting to, for example, h:\%username% and the appropriate folder will be created (assuming your H drive is mapped appropriately). When users logon, the map drive is connected through their profile.  When you setup the BDE alias, just point to this drive and all is well.  The reason we build separate folders for each user's local tables is to prevent one user from overwriting another during concurrent processes.

Too good to be true?

TS is certainly not the end-all to WAN’s.  Security is, as always, a serious consideration and something that requires frequent review.  You will essentially have a server with company-specific data constantly connected to the Internet.  Add to this the fact your database may contain critically sensitive personal information regarding your clients or customers.  Complicate this even further if your TS server is part of your LAN domain and security had better be high on your list of priorities.  Since Explorer is an integral part of the Windows O/S, users will, at a minimum, be able to view all of the folders on the server.  There are other areas to consider that are beyond the scope of this article, but suffice it to say your administrator needs to be well versed in security and TS.  TS is not something for the reckless at heart.

Other Options

Citrix is an alternative/addition to TS in that it provides additional capability, e.g., internet appliances, sound, high color display, etc.  Additionally, in certain instances, Citrix provides some additional capability in limiting client access to certain folders/functions on the server.

Terminal Server shortcomings

As mentioned above, TS cannot be expected to handle all of your clients automation needs, especially not on a single server.  In its current version, a user cannot save a file to her/his local drive from the terminal server.  Of course, they may be able to drop it into a folder setup for FTP and then connect via an FTP client and transfer the file.

System administrators have difficulty limiting the options at user logoff: for example, the user may opt to disconnect instead of logoff.  Fortunately, you can prevent access to the restart and shutdown functions.

As with any process dependant upon the internet, a dropped connection in any of the hops between the client and the server may cause a disconnect.  If some ISP out there decides to reboot a router… well, you know the rest.  Fortunately, the administrator can establish certain rules regarding dropped connections, etc.  Additionally, you can configure your TS to pick up where a user left off in the event of an “unplanned” disconnect.

Running a data-centric application on a terminal server is somewhat different than running a web-enabled data-centric app.  As with any LAN application, precautions must be taken to ensure data integrity.  That said (fingers are crossed here), we have yet to experience a case of data corruption with our terminal server applications.

Is Terminal Server for you?

Only through a fairly intensive analysis can this be answered.  In closing, I’ll offer you this; in many instances, TS should be a serious contender.