Timothy
Parker Consulting Incorporated
|
|
|
|
Remote Access Servers After a rather lengthy look at setting up a Web server, it's time to move on and look at a few shorter subjects. We'll start off with an issue that has becoming more important over the last two years: remote access servers. The popularity of remote access servers (RAS) is directly due to two reasons: more people are starting to work at home instead of going in to the office, and more people are working from home after leaving the office. It's not uncommon to access a work server at night to check e-mail, catch up on a project, or do some late-night catch-up. Remote access servers are nothing new. They've been around since the early days of UNIX, when dial-in modems allowed access to character-based sessions. Back in those days, the amount of work you could do over the slow modems was rather limited, especially since corporate-wide e-mail was still evolving, but the mechanism was there. Now, fast modems and fast servers, remote software that provide efficient use of windowed applications, and the need to constantly stay on top of office work has led to many companies and organizations setting up dedicated communications server. In the next few columns we'll look at how to choose the equipment for several sizes of remote access servers, the type of hardware and software you need, and peripherals issues like the capabilities a remote user has access to. Let's start with setting a couple of basic parameters about the size of the server and the number of lines involved. A rule of thumb from the "old days" of the late eighties and early nineties (pre-Windows) was that for every 100 workers you needed a single phone line. Although real numbers are hard to estimate today, a lot depends on the type of work that is being done. For systems I've installed over the last four years, I've assumed a much lower ratio of one phone line for every 30 workers. For high-technology companies, this ratio is dropped even further (even to 15 to one) as many programmers work late hours, project managers check status of projects and e-mail before retiring at night, and company management fire off late e-mails to make everyone else think they work late! For sales-based organizations, the ratio rises a little as there's much less traffic in most of these types of businesses late at night. Remember that these numbers are a starting guess. Only time and monitoring of the system will tell if the number of lines in to the server are too low or too high. For this reason, you should plan on the ability to double the number of lines without replacing all the RAS equipment. This can be an important issue. One client was convinced all they needed was eight lines, and when employees complained about lousy access after hours, a completely different system had to be purchased wasting several thousand dollars. Plan ahead: clients will appreciate it in the long run. There's also the chance of overestimating need as well. It's embarrassing (and expansive for the client) to install a 16 port RAS only to find out there are no more than four ports were needed. Unfortunately, these things will happen and you can only learn from experience and guesswork. For simplicity, we'll divide RAS systems into three categories, only two of which we'll consider. The one we'll ignore are those very large organizations that require hundreds of lines, dedicated minicomputer-like remote access switches and servers, and complex telephone line combinations like optical fibre. For these large systems, hire one of the companies that specialize in the setup and configuration, as the costs are amazingly high. The two categories we will consider are the small company that requires one to four (or so) lines at most, and the most common category, those organizations that need between four and a hundred access lines. Both these categories can be serviced by a Pentium PC and some add-on RAS hardware, can be configured by any knowledgeable VAR, and don't cost an arm and a leg. There are really only two operating systems to consider: Windows NT and UNIX. Sure, Windows 95 (and Windows 98) can be configured for a few dial-in modems, but it lacks the multitasking capabilities that dial-in requires, as well as security and access control features that button up the client's network. Between Windows NT and UNIX (or Linux) there really is not much difference. There is a ton of third-party hardware and software for each platform, and many that cover both platforms equally well. In most cases, the Windows NT software is easier to work with since it's all a familiar GUI. However, UNIX is slightly more flexible and able to handle higher loads. Choosing the operating system just for the remote access server is silly: use the platform that the client uses. If they haven't got a UNIX box in house, don't suggest one. On the other hand, an all-UNIX engineering company may shiver in dread at the thought of a Windows NT server. If you choose Windows NT, you need the Server version (the workstation release does have some capability for RAS support, but the Server is much better). Version 4.0 or 5.0 (if it's released) work just as well. Version 3.51 is also suitable if the client has not upgraded yet, although there are fewer drivers for the older release. For UNIX, any workstation or PC platform such as SCO OpenServer and SCO Unixware will suit. Linux is a possibility, but there is the lack of commercial support to consider, as well as the lack of as much variety in hardware choice. Starting with the next column, we'll look at both operating systems in turn, as well as how to configure several of the excellent RAS systems that are now available. |
|
Send mail to
tparker@tpci.com with
questions or comments about this web site.
|