Three NT-based Remote Access Servers

Test Track: Remote Access Servers

It’s no big secret that the working world is becoming more mobile. What with notebook computers and cellular phones, many people are taking their jobs on the road. And others are simply working from remote locations, such as home or branch offices. In fact, according to a recent study by International Data Corp. (Framingham, Mass.,, the number of employees remotely accessing corporate LANs is rising steadily. (See related story, IDC Says More People Are Working Away From the Office) As that number grows, so does the need to provide access for remote workers and road warriors.

One method of providing access to the Windows NT servers within a LAN is a Windows NT-based remote access server. Tight integration with existing systems and hardware, easy sharing of user information and permission structures, and easy inclusion into existing administrative capabilities are all good reasons to consider one of these machines for an NT shop.

Our criteria for this review of Windows NT Server-based remote access servers was support for at least 30 simultaneous connections, out-of-the-box integration, 64 MB of RAM, a single hard drive, a 1.44-MB floppy drive and a 16x or faster CD-ROM drive. We also required an integrated 10/100Base-T Ethernet port, along with T1 interfaces and digital modems to meet our 30-user minimum. In practice, this meant that each machine had two T1 ports and 48 digital modems.

Compaq 5601 Remote Access Server
Compaq Computer Corp.
Irving, Texas
(800) 345-1518
Price for test configuration: $22,556

Compaq's RAS hardware is based on a 266-MHz Pentium II CPU (expandable to two processors), and comes with 64 MB of RAM (expandable to 512 MB) and a single SCSI-3 hot-pluggable 4.3-GB hard drive (expandable to three drives). RAScom provides the T1 interface.

Although this is a relatively modest hardware set, Compaq is offering more possibilities for expansions and upgrades than our other test subjects. If the remote access server is only destined to perform as a remote access server, this may be irrelevant. But it might be a natural addition to the capabilities of this NT server to install a firewall, Web-caching services, a proxy server or other applications that might logically be placed on the outer perimeter of a network. If the need for those extra services is expected to arise, or if the full remote access complement of four T1 lines and up to 96 simultaneous connections is added, the expandability of the server hardware may become quite significant.

Upon the first power-up, an automated software installation of all the bundled software began. We were prompted for name and organization, time zone, license number, machine name, and so forth, as would normally occur in an NT installation, but were not asked to set the administrative password or the server type, such as primary, backup or standalone. The password can be changed readily enough, but it might not always be a safe assumption that the server would be a standalone type. The Internet LANbridge software also brought up a message box during the installation that listed the five detailed steps necessary to configure it prior to starting the Internet LANbridge Server service. We found this to be an awkward way at best to convey important configuration information; we would have preferred to install the software separately and be prompted through the process.

Compaq, like the two other systems, uses Virtual Motion's Remote Access Manager software for control and administration of remote-connecting ports and users. It allows management of port and user characteristics that Windows NT's Remote Access Services do not address, and greatly simplifies most management tasks. The main window shows each available port as a button, which is gray when not in use, yellow when a connection is initiated, and green when a link is established. Double-clicking on a green port button brings up an information screen that gives all of the vital statistics on that particular port connection, including username, start time and duration of session, and a wealth of information on the port condition and possible errors.

Administrators can also use the Remote Access Manager to impose connection limits on the basis of time of day, connection duration and idle time. There is a limited notification function that will send an SMTP e-mail message when triggered by a specific logon or logoff, CRC error, line-speed change or number of received/sent bytes. It would have been very useful to have more notification mechanisms available, such as output to a network printer, paging, or a sound cue or program execution.

There are several different summary views available that give details of all users or all ports, or a session log that shows user, port, IP address and time information on all sessions. These view windows allow quick and easy access to most commonly needed sets of information to show RAS utilization, and can also assist in troubleshooting.

This software did exhibit one minor foible. During one test session, neither the RASview or Remote Access Manager modules would start up normally, both instead posting a message box that said there was no remote access server available. This seemed particularly odd since the software was installed and running on the remote access server in question, but a repeated startup attempt went smoothly.

The Compaq 5601 offers an attractive package by combining the established server hardware capabilities of Compaq with the T1 interface provided by RAScom, and the management software of Virtual Motion, to offer the most capable and flexible system that we reviewed.

RAScom RAServer 2100
RAScom Inc.
Salem, N.H.
(603) 898-5200
Price for test configuration: $27,000, including two T1 interfaces and 48 digital modems.

RAScom is the specialist company in this group. Its sole market focus is in the remote access area, and the company’s offerings are attractive enough that Compaq, Acer America Inc. (San Jose, Calif., and NEC America Inc. (Herndon, Va., are all licensing the RASware software package and the WAN technology that RAScom has developed since the company opened its doors in 1996.

Like the two other units we tested, RAScom’s RAServer 2100 ships with Virtual Motion’s Remote Access Manager software. The RAServer 2100 uses the most basic PC platform of our group, with a 166-MHz Pentium CPU, 64 MB of RAM and single 1.2-GB hard drive. While this may be sufficient to support the configuration in our test, it seems a bit lightweight for a platform that might be asked to handle several additional processes and services. The small hard drive and lack of any sort of SCSI interface seemed particularly odd in a server-class machine in this price range. RAScom does offer RAID storage and redundant power supplies in the high-end 2600, but this comes at a significant price increase over the 2100.

One advantage to purchasing from the technology developer in this area is that you receive the most current versions of the relevant operating software, which might not be the case in a third-party purchase. In this case, our RAScom 2100 included the Routing and Remote Access Service (RRAS) upgrade to Windows NT, formerly known as Steelhead, in its operating system. Although this upgrade is freely downloadable from Microsoft Corp., it is not an easy upgrade to an existing system. Not only does it require a carefully choreographed sequence of steps in order to install properly, but it will also overwrite settings in the existing Remote Access Service. This would seem to make it an impractical addition to any existing installation, however desirable it might be in a new one. There have also been a quick succession of interlocking hotfixes and RRAS versions, making it difficult to keep track of which does what.

RAScom does its best to keep all of this straight by supplying the RRAS hotfix on diskette, along with the Point-to-Point Tunneling Protocol (PPTP) hotfix needed by the later releases of Virtual Motion's software, but it is still an administrative nightmare to handle version control in this fluid environment.

It helps that RAScom supplies its servers in ready-to-go form, with all software installations and settings done at the factory. We had to make a phone call to find out the administrative password, and that should have been all we needed. Unfortunately, our test machine had been configured for ISDN service instead of T1, so we spent some time changing the settings and wading through multiple reboots, as prompted by RAScom's capable tech support, before we could establish communication.

Once up and running, we were faced with a system that was an essential duplicate of our Compaq machine. With the WAN boards, interface and driver software (RASware), and management software (Virtual Motion) almost identical on each, and with no glaring differences in performance, the Compaq and RAScom are operational twins. We did have one odd failure with the Virtual Motion suite in the RAScom machine: After most of the testing was complete, the RASview and Remote Access Manager programs reported a missing pointer in the same DLL file, and would not run. A version upgrade from the supplied 1.42 to 1.44 failed to fix the problem. (Compaq supplied version 1.4.07, which might explain the slightly different oddities shown by each version.)

In the final analysis, it is hard to balance the higher cost and less-robust hardware of the RAScom against its closer-to-the-edge qualities in software. Our preference would be for the better hardware, and what might be a slightly safer software package.

3Com SuperStack II 3000 Remote Access System
3Com Corp.
Santa Clara, Calif.
(408) 764-5001
Price for test configuration: $23,485

3Com's attractive modular SuperStack II 3000 system comprises Access Concentrator Modules (ACM) and the EdgeServer. The system offers the greatest expansion possibilities in our group, with the capability of stacking up to six ACMs to one EdgeServer. The concentrator modules connect to the EdgeServer, which is the actual remote access server, to enable more users to connect to the EdgeServer. With the concentrator modules, there is the potential for 144 ports, or six channelized T1 connections, per server. Unfortunately, we had serious difficulties in persuading our 3Com hardware to communicate with our test chain.

3Com falls in the middle of our group in its hardware platform for the EdgeServer, with a 200-MHz Pentium Pro CPU, 64 of MB RAM and an Adaptec SCSI adapter. The system board will support dual CPUs if expanding capabilities warrant, but the hard drive is relatively small (2.1 GB). Oddly enough, the SCSI adapter has no attached devices within the base system, and so offers only potential benefits.

The separate ACM incorporates the T1 and digital modem capabilities in a slim, rack-mountable case with its own LCD for configuration and status information. High-availability design points include connectors for an external redundant power supply and a terminal connection, should intensive debugging be needed.

It quickly became apparent that the 3Com ACM was going to be difficult. We went through what seemed to be the appropriate configuration process to match up with our Lucent Technologies' emulator; but despite repeated attempts, many calls to 3Com and Lucent for help, and even a replacement ACM, we failed to establish communications. We consistently received a carrier indication but never were able to get a dial-in call answered. Ultimately, 3Com sent a technician and a Madge Networks Access Switch 60 from its lab to serve as a T1 emulator. This combination worked but still leaves the large and puzzling question of why a T1 line that worked perfectly with the Compaq and RAScom machines could not be made to work with the 3Com system.

As with the two other systems, the 3Com is bundled with Virtual Motion’s Remote Access Manager, as well as 3Com's own Transcend Remote Access Manager (TRAM), which offers control of the ACMs through an easy-to-use graphic that duplicates the front-panel layout. Unfortunately, here again we were assailed by gremlins: Every time we tried to make a change to the ACM through the TRAM interface, we received a message stating that the action had not been completed because of an SNMP failure. This severely limited the utility of the TRAM.

With only two actual T1 interfaces (3Com and RAScom) being used in our group, we can't draw conclusions about the connection problems with any confidence. However, the fact that no amount of assistance was able to solve or even explain this problem leaves us skeptical about 3Com's capabilities in this area.

For a look at more remote access servers, surf on over to

Through the Test Track

In order to put these three remote access servers through the paces, we built a test network. We used a Definity Prologix PBX unit with T1 expansion modules from Lucent Technologies Inc. to emulate a T1 connection. This telephony array served as our dial-in point and T1 emulator. Lucent even has a remote access option for the Definity system, but it did not fit our test criteria and was therefore not used.

Each of the remote access devices in our test is also a lightly configured Windows NT Server (64 MB of memory, 1 to 4 GB of hard drive space), and required network configuration and setup in order to join the test domain and accept dial-in logons. Coincidentally, all three systems shipped with Virtual Motion’s Remote Access Manager software for control and administration of remote-connecting ports and users.

The test chain in its final form consisted of a Hewlett-Packard Co. Kayak workstation and U.S. Robotics 33.6-Kbps external modem for our dial-up client, dialing into the Lucent Technologies Definity Prologix PBX and then connecting through to the T1 interface of the remote access device under test. The test device was also linked via Ethernet to the Dell Optiplex server that functioned as our domain controller, and also provided Microsoft Exchange services for e-mail and file transfer applications.

Each machine was substituted into our test network, and the available management software on each was used in as many capacities as possible to monitor, control and troubleshoot the dial-in client sessions.

With all three servers, we needed to provide the T1 adapter with the proper settings to communicate with our T1 emulator, as well as the TCP/IP settings for our private network. In each case, some additional tweaking was needed for the T1 interface as well, but once everything was set properly, it was as straightforward as a modem connection.

And, like a properly set-up modem connection, the T1 leg of our test chain ceased to be a noticeable part of the process once it was operating. At that point, the hardware became appropriately transparent, and our dial-in client was able to reliably establish a dial-up networking connection.