NetWare 2.x Notes

Novell NetWare has quite a long history, but the older parts of it are now almost completely lost. In the mid-1980s, Novell offered Advanced NetWare, NetWare ELS, NetWare SFT, and other members of the NetWare 286 family.

With the partial exception of so-called non-dedicated NetWare 2.x servers, version 2.x and later of NetWare always had dedicated server machines with clients (called “shell” in the old days, later “workstation”) for DOS, OS/2, Macintosh, and more.

Until the mid-1990s NetWare typically used its own networking protocol called IPX. NetWare networks could use Ethernet, Token-Ring, Arcnet, IBM PC Network, and other physical network layers. In later days, NetWare networks were almost exclusively Ethernet based (as the other technologies died out), and over time increasingly switched to TCP/IP transport.

In 1989, NetWare 386 was released, to be followed by 3.1, 3.11, 3.12, and 3.2. NetWare 386 was one of the first 386 operating systems for the PC; while it lacked some features of other contemporary advanced operating systems (such as pre-emptive multi-tasking), it had others, like dynamically loadable and un-loadable modules. NetWare 3.x had a long life and survived into the Internet era, including its PDF documentation.

In 1993, NetWare 4.0 was an update to the 3.x line with directory services and other add-ons. Technically NetWare 4.x wasn’t very different from 3.x, and together NetWare 3.x and 4.x were the mainstay of many networks small and large for many years.

NetWare 3.x and 4.x had the curious property that the core of the 32-bit OS (SERVER.EXE) was loaded from DOS, with the ability to exit back to DOS once the NetWare server was “downed” (using the DOWN command, then EXIT).

NetWare 286

NetWare 2.x was… different. A dedicated NetWare 2.x server was installed in its own partition and did not require DOS to boot at all (in that regard it was like NetWare 6.0). It also did not use loadable modules, which made maintenance somewhat challenging (there were VAPs, or Value-Added Processes, mysterious and rare add-ons).

The way NetWare 286 was configured was not unlike many commercial UNIX variants of the era. That is to say, the OS kernel and drivers were provided as object files (regular OMF objects with .OBJ extension), and reconfiguring NetWare meant re-linking the OS. The client side software was managed in the same manner, with the appropriate network driver linked into IPX.COM, to be used by the shell.

Installation and configuration required DOS. It was also designed to not require a hard disk–that is to say, it could be started using a bootable DOS floppy and copied from floppies onto the dedicated server. Especially for NetWare versions prior to 2.2, this was a rather painful process requiring several dozens of 360K floppies. Due to the non-requirement of hard disk, some of the floppies were modified during installation and it was advisable to use working copies, not the original disks. Once a NetWare server was on a LAN, it was possible to install using a directory on the file server, massively reducing the floppy juggling.

While the installation process is more annoying than difficult, there are parts of it that are not in the least obvious, even to people familiar with later NetWare 3.x and 4.x versions. NetWare 2.x was meant to be installed by trained consultants and resellers, which explains why it remained somewhat esoteric.

Matters are further complicated because although NetWare 2.x in fact comes with extensive on-line help, which includes documentation for administrators, the help files are designed to be only available on a shared network drive after installing NetWare. Then again, NetWare used to be delivered with many pounds of printed documentation detailing the install process… with almost all of it completely lost to the sands of time.

Installing NetWare 2.2

NetWare 2.2, released in 1991, was a consolidation of previous NetWare 286 offerings: NetWare ELS (Entry Level Solution), with only 4 or 8 users; Advanced NetWare; and NetWare SFT (System Fault Tolerance) with technologies such as disk mirroring. NetWare 386 at the time was relatively expensive, starting at about $3,500 (20 users), while a basic NetWare 2.2 license (5 users) was about $900. NetWare 2.2 installation was somewhat different and easier compared to the older versions, and therefore is worth discussing separately.

Given the multitude of disks and the workings of the installer, disk naming is crucial. Working floppies or floppy images must be named SYSTEM-1, LAN_DRV_001, or OSEXE; simple numbering just won’t do.

The installation and maintenance tool in NW 2.2 is called INSTALL.EXE and therefore not difficult to find (in NetWare 2.15 it’s not that simple). It can be used for installing a new NW 2.2 server, reconfiguring an existing one, or upgrading an older NetWare 2.x server.

When installing a new machine, there are two options: Basic and Advanced. The Basic variant assumes NE2000 networking hardware in its default configuration and is therefore probably not applicable. The Advanced option allows the system administrator to choose the network and disk configuration.

Disk Drivers

Hard disk support is where trouble may start. Out of the box, NetWare 2.2 effectively only supports classic AT disk controllers or early IDE drives. No geometry translation, no LBA (then again it’s fine with a 120MB disk, so who cares).

Worse yet, NetWare 2.x has an interesting restriction in that the FDPT (Fixed Disk Parameter Table) must be placed at segment C800h in memory or higher. In practice that means NW 2.x refuses to work with user-defined disk parameters with BIOSes that store the geometry either in low memory (0:300 is common) or in the EBDA. A fix to remove this requirement was available.

Vendor-provided HBA drivers for NetWare 2.x were not common but did exist.

Network Drivers

NetWare 2.x came with a decent selection of drivers for networking hardware available in the late 1980s. That is to say, a handful of drivers. About the only one that isn’t totally obsolete is NE2000–the drivers shipped with NetWare 2.x may work on later NE2000 compatibles.

Some vendors did provide drivers for NetWare 2.x servers in the 1990s. Those were provided in the form of a .LAN file and usually four or more .OBJ files.

Even after finding a functioning NetWare 2.x server driver, the fun is not over. The default Ethernet frame type changed from 802.3 (raw IEEE 802.3 Ethernet) in NW 2.x to 802.2 (IEEE 802.2 LLC) in NW 3.12 and later. What that means in practice is that servers and clients using different frame types won’t see each other on the network.

Note that as for NetWare 2.x clients, NetWare 2.2 already provided ODI as an alternative, and using newer ODI-based clients is generally not a problem with NetWare 2.x servers. The “native” way of setting up NetWare 2.x clients was using SHGEN (Shell Generator) or later WSGEN (Workstation Generator) to link IPX.COM with a specific driver in a more or less fixed configuration.

For NetWare 3.x and later, it’s relatively easy to support both Ethernet frame types (or even more). NetWare 2.x Ethernet drivers cannot be reconfigured to use an Ethernet frame type other than 802.3. However, there is a virtual 802.2 driver (A8022.LAN) which provides 802.2 frame support in addition to the default 802.3 frames.

It is also necessary to understand that while NetWare 3.x and later servers can easily handle multiple Ethernet frame types, NetWare clients can not. Newer clients can be configured to use Ethernet 802.3, 802.2 LLC, or plain Ethernet II frames, but only one type can be used at a time

Every NetWare server and client can work with 802.3 frames, but it is not the default on newer NetWare versions. Caveat emptor.

Installing NetWare 2.15

Here it gets a lot more complicated. The first question is, which NetWare 2.15? There’s ELS II, there’s Advanced NetWare, and there’s SFT.

Note that this is not meant to be a tutorial but rather a collection of notes explaining some NetWare features and pointing out certain tricky parts of the installation process.

First of all, there are two conceptually separate steps in installing NetWare 2.15. One is generating the NetWare system, and the other is preparing the server’s disk.

The name of the system generator depends on the NetWare flavor. For ELS II (probably the most widespread flavor of NetWare 2.15), it is ELSGEN.EXE, and it is found on the ELSGEN disk. For Advanced NetWare, the installer is NETGEN.EXE on the NETGEN disk.

The installation uses a full-screen menu-oriented user interface, which is not difficult to use as such, and provides decent guidance. It does have certain idiosyncrasies, such as the following:

Yes, press Escape to continue. No, it does not make any sense, and for the most part NetWare menu-based utilities use the Escape key in the usual fashion.

When setting up a new server, the IPX network address has to be chosen. For all servers on the same LAN (and using the same Ethernet frame type), the address must be the same, or the servers will complain. The actual address matters little; in newer NetWare versions, the number is randomly generated, in old versions it has to be manually entered.

Once the server OS is generated, it must be installed on a server. That includes choosing a disk…

…and running the dreaded COMPSURF utility (COMPrehensive SURFace test). COMPSURF was a tool designed for 1980s dumb drives that had no media defect management. NetWare did it all on its own, identified bad sectors, replaced them with spare sectors, and so on. On a file server, data integrity was obviously quite important.

At one time it was even possible to buy COMPSURF-ed drives that would avoid the need to run COMPSURF, which on a larger drive was a process that took a number of hours.

COMPSURF is not very nice. It completely destroys all data on a disk.

Once COMPSURF is done and the disk is prepared, NetWare volumes can be defined:

After that, the “cold boot loader” can be installed. That way, NetWare can boot off a hard disk (which is actually optional, it is possible to boot from floppies as well).

Once the server is prepared, it’s off to the races. The server can boot, and clients can connect to it.

Booting a NetWare 2.15 ELS II server in a VM takes about one second (yes, really). Booting a DOS 3.3 VM that connects to the server takes even less. It’s blazingly fast, and a huge change for anyone used to the IBM/Microsoft protocols based on various implementations of NetBIOS.

From a running DOS client, it’s possible to run e.g. FILECON and check the server version:

Note that after the server is installed, there are a few things that need to be done from a client, such as installing on-line help (see HELPLOAD.EXE). That part is entirely optional an can’t be done together with copying all those PUBLIC floppies.

Non-Dedicated NetWare

A curious feature of NetWare 2.x which has no equivalent in NetWare 3.x and later is non-dedicated servers. As mentioned above, there are two ways to generate the server executable, dedicated or non-dedicated.

A dedicated server boots directly off the hard disk like a normal OS and takes over the machine. A non-dedicated NetWare server is not bootable. The machine must first boot to DOS, then run NET$OS.EXE. That starts the NetWare server and goes immediately back to DOS (with NetWare still running in the background). At that point, DOS manages the first megabyte of memory in real mode, while NetWare controls everything above that.

Note that the hard disk is not bootable because it is not a DOS disk. That is a huge caveat of non-dedicated NetWare–the hard disk is formatted using the NetWare file system which DOS does not understand.

Once a non-dedicated server dropped out to DOS, it is possible to get back to the server console by running CONSOLE.COM, and it is possible to return back to DOS again by running the appropriately named DOS console command.

A disadvantage of a non-dedicated server is that because it runs DOS in real mode, it is quite easy to hang the system, or in a less extreme case, significantly interfere with the file server’s performance. So why would anyone want to use a non-dedicated server? One possible reason is that on a non-dedicated server, it is possible to run all DOS-based NetWare management tools directly on the server machine, without requiring a workstation attached over the network–something that only came back in NetWare 5.x.

Note that when in DOS, a non-dedicated NetWare 2.x server has the equivalent of IPX.COM already running. It is still necessary to run a NetWare shell (NETx.COM, NETX.EXE, etc.) but there is no network driver to load. Logically the DOS workstation running locally on a non-dedicated server exists on a separate virtual network between the server and the DOS process, and the server’s virtual adapter is called “Non-Dedicated Server DOS Process”.

Yes, there is a lot to absorb, and these notes aren’t even all that comprehensive.