In this chapter you are introduced to network services that are available through a NetWare 4.x-based network. This chapter defines the basic networking components used in a NetWare 4.x network and teaches you ways to configure a DOS workstation for logging in to the network. You are also taught the different networking components that are used on a DOS workstation and the functions each component performs.
In addition, you are presented with an overview of the services and features available in NetWare 4.x.
You can visualize a network as a system that connects computers in a manner that enables the computers to share information. The computers are classified based on the kinds of activities that are performed on them. Figure 1.1 displays a network with several types of computers. Some of these computers are dedicated for personal use by a network user. These are called workstations and can run a variety of different operating systems, such as DOS, OS/2, Macintosh OS, Unix, and Windows NT.
Figure 1.1 Network components.
Other computers on the network provide specialized services that other computers can use. These computers are called servers and, depending on the services they provide, they are called file servers, database servers, and communication servers. A NetWare 4.x server is an example of a server that enables the sharing of resources, such as file services, to users on the network. Other types of servers provide database access or communications access and are, therefore, called database servers and communication servers. The network can also have larger computers such as minicomputers and mainframes that act as servers.
The operating system that runs on the servers is either a general-purpose operating system, such as Unix, OS/2, or Windows NT, or a specialized operating system, such as NetWare.
The workstation typically makes requests for services from servers and is therefore called a client of the network's server components. For communications to take place, the workstation needs to have physical network components, such as cabling and network cards, and network devices, such as repeaters (to amplify signals over long distances). Larger networks often have interconnecting devices such as bridges and routers to interconnect networks at OSI (Open Systems Interconnection model) layers two (data link) and three (network), respectively.
Figure 1.1 shows one possible type of a network. Because of the small distance span, such a network is called a local area network (LAN). Another type of network is the wide area network (WAN), which can span long distances. NetWare 3.x and early versions of NetWare were designed to run on LANs, where they provided workgroup computing solutions. You can use NetWare 3.x (and earlier versions) in WANs, but on large networks, current releases of NetWare 3.x begin to show weaknesses in the areas of network administration and communication. NetWare 4.x was designed to address these weaknesses and is utilized in both LANs and WANs.
NetWare 4.x can also be used for integrating LAN and WAN environments. Figure 1.2 and table 1.1 show the differences between LANs and WANs. A primary difference is that LANs are generally owned and operated by a department of an organization or a group of users, whereas WANs lease a commercial service or use expensive private technologies.
Figure 1.2 LANs and WANs.
| Parameter | Local Area Networks | Wide Area Networks |
| Ownership | Owned by departments and end users. | Not generally owned by an organization. Services are provided by commercial organizations. |
| Distance | Short: within a building or campus (less than 10 KM, typically). | Long: Across country, between countries. |
| Media Choices | Many: Twisted-pair, coaxial, fiber-optic, and so on. | Relatively few: Leased lines, telephone lines, fiber-optic. |
| Protocols | Many: IEEE 802 LAN protocols, TCP/IP, SPX/IPX, AppleTalk, ATM, and so on. | Relatively few: X.25, TCP/IP, ATM, and so on. |
| Data Transfer | Typically high-speed: 1 to 100 Mbps. Availability of ATM may blur the differences between LANs and WANs. | Typically low-speed: 2400 bps to 64 Kbps. Higher speed networks are becoming available. Availability of ATM may blur the differences between LANs and WANs |
As you can see from figure 1.2, LANs usually cover shorter distances. Most LANs today are based on a shared-media access technology that limits the distances across which LAN cabling can be run. This means that the network devices share a common network media, such as coaxial cabling or twisted-pair wiring, and have to use a method of communication that does not interfere with signals from other network devices using the same media. Examples of this are the CSMA/CD (Carrier Sense Multiple Access with Collision Detect) technology used in Ethernet LANs and the Token Access technology used in token-ring networks. These shared-media access technologies are limited by distance and do not function efficiently over the longer distances required for WANs.
For LAN networks that have larger network bandwidths, switching technologies such as the type used in switched Ethernet, switched token ring, and Local ATM (LATM) networks can be used.
WANs must use underlying protocols that work well over longer distances. Examples of these are X.25, Frame Relay, SMDS, SONET, ATM, and so forth. Discussion of these technologies is beyond the scope of this book. You can refer to another book, NetWare: The Professional Reference, for more information on WAN technologies and Ethernet switch technologies.
The media choices that are available to LANs are wide-ranging and include such types as twisted-pair, coaxial cable (coax), fiber, wireless, and others. WANs are often limited to whatever media choices are already installed. A new media type is sometimes difficult and expensive to install over the long distances typical of WANs; likewise, the long distances might also affect right-of-way issues.
A network can consist of several LANs tied together with wide area links, as shown in figure 1.3. For a user to use printer or network volume storage resources, the user has to know the location of the resources. For earlier versions of NetWare, such as the one depicted in figure 1.3, the user needs to know the names of the file servers to which the printer and volume resources are attached. Before accessing a resource on a server, the user has to log in to that server.
Figure 1.3 An example of a NetWare-based network.
If the user needs to access a volume resource on another server, he or she has to attach to that server. Attaching and logging in to a server implies that the user needs accounts on each server that he or she intends to access. This approach works quite well in small networks that consist of less than 50 computers. On larger networks where there may be many servers, it is not easy for the user to remember the resources that are available on each of the servers. In such cases, it is much easier for the user to have a logical view of the network that hides the network's nonessential physical details. Figure 1.4 shows a logical view of the same network depicted in figure 1.3.
In the network's logical view, resources are organized into groups that are, in turn, organized into a hierarchy that reflects their usage, function, or geographical location. To utilize the resources on this network, the user logs in to this logical view of the network. Security mechanisms that are global in scope and apply to the entire network control access to network resources. In NetWare 3.x and 2.x, access to resources is controlled by security mechanisms that are local to each server (called the bindery). The bindery does not have network-wide significance; the bindery-based services, therefore, are server-centric. To provide a single access to the network, the designers of NetWare 4.x created a global database called the NetWare Directory Service. The NetWare Directory Service is the mechanism used to supply a logical view of the network.
Figure 1.4 A logical view of a network.
The NetWare Directory Service's global database service is not confined to a single server; it represents network-wide resources. This distinction is the single most important difference between NetWare 4.x and NetWare 3.x/2.x. It is also the feature that affects many of the network administration tasks and network utilities. Many pre-NetWare 4.0 network administration tasks and utilities modified the network information in the bindery. The NetWare 3.x/2.x utilities cannot be used for NetWare 4.x because the information in a global database needs to be modified, and these older utilities have no concept of a global database, although they understand the bindery. Several older utilities have been consolidated into newer ones. These newer utilities have the capability to correctly modify the global database.
Before you can understand ways to administer and make a connection to a NetWare 4.x network, it is helpful to have a general understanding of the way NetWare Directory Services (NDS) works. NDS is the most distinctive feature of NetWare 4.x over earlier NetWare versions. It provides the network administrator and the user with a logical view of a network that hides the sometimes bewildering complexity of the actual physical network topology. An organization can arrange the logical view of its network in a way that meets the organization's needs and is easily recognizable to the network's users. Figure 1.5, for instance, presents a hierarchical view of the network that reflects the organization chart of a company and is recognizable by the company's network users. The physical details of the network (such as its type of cabling) and its interconnecting devices (such as routers and bridges) are not considered in figure 1.5. In other words, the network administrator and the user do not need to be aware of the physical nature of the network to use the network.
Figure 1.5 A logical network that reflects the hierarchy of an organization
The logical view is possible because of NDS. NDS provides a distributed database that can act as a repository of information on all the shared resources on the network. The database is considered distributed because it does not physically reside on any single server on the network. The database is hierarchical because it provides a convenient grouping of resources by function, location, or organizational structure.
NDS is essentially a replacement for the bindery services that are part of the pre-NetWare 4.0 product line. The bindery in the earlier NetWare release is also a way of organizing resources, but the resources are specific to the server on which the bindery resides. The bindery cannot easily support information on other network nodes, and because it is organized as a flat database instead of a hierarchical database, it does not have any natural way of representing usage or organizational relationships between resources.
If you were to categorize some of the benefits of using NDS, they would be as follows:
STUDY NOTE: Novell's implementation of NetWare Directory Services for NetWare 4.x provides the following:
- Multiple levels of security
- Printer and file sharing
- Centralized or distributed network management
- Logical organization of network resources
The logical organization of the network is a benefit that derives directly from the way you can group resources hierarchically in an organization's NetWare directory service representation (see fig. 1.5). This grouping is executed to reflect the way users want to use the network, making it easy for users and network administrators to find the network resources without knowing the physical details of network connectivity. A user who needs to use a network resource has access to NDS objects in the database that contain information on the network resource. In NetWare 4.x, all network resources accessible by NetWare users are represented by NDS objects.
STUDY NOTE: NDS controls access to objects and resources on the network and eliminates redundant tasks such as adding a user account to multiple servers on the network.
An example of a network resource is a file server, which you can model as a File Server object. Inside this File Server object (see fig. 1.6) is information such as the name of the file server, its network address, location, and so forth. Information about the file server is described by the properties of the File Server object.
Figure 1.6 A file server represented as an object.
A single login to a network (see fig. 1.7) enables a user to be authenticated just once in order to access all the resources on the network. After the user logs in, the network administrator can limit his or her access to resources on the network. For instance, all users, by default, are permitted to see the structure of an organization's directory, even though they cannot access all the objects in this directory unless explicitly given access by a network administrator. A single login to a network also simplifies the use of the network, because the user does not need to perform separate logins on multiple servers on the network.
Figure 1.7 A single login to the network.
Before NetWare 4.0, the user was required to log in (or attach) explicitly by supplying a user name and password for every server to which he or she wanted access. The number of such concurrent connections was limited to eight. In addition, the network administrator had to create separate accounts on each server that the user needed to access. This easily became a burdensome task on large networks.
The single login to a network is possible because the user authentication takes place against a global network database (directory) that is not specific to a server. In figure 1.8 you can see that the first step to logging in to a network is the authentication of the user against information in the global directory. Once the user authentication is successful, the user is granted access to any resource on the network. The maximum number of concurrent connections to different NetWare servers is now 50; for pre-NetWare 4.0 versions, this limit is 8.
Figure 1.8 User authentication to the network.
The previous sections have described the purposes of an NDS tree and ways that you can use a single user login to log in to the entire network. This section discusses the components and procedures needed to make a network connection. Before a user can log in to the network, the user must make a connection to the network.
When a workstation makes a network connection in NetWare 4.x, it is not just connecting to a particular file server on the network, but is also connecting to a global database of resources accessible to users at any workstation. This global database contains the definition of the user accounts. The user can log in to the network using a valid user account in this global database that is implemented by NDS.
To make a network connection, you need additional hardware support in the form of a Network Interface Card (NIC) attached to the network. The NIC is responsible for the physical interface to the network. In addition to NIC hardware, networking software, consisting of the NetWare requester and communication protocols, is also needed to provide access to the NetWare 4.x network (see fig. 1.9). A communication protocol is a set of rules and regulations on ways to format and send messages between two computers. There are many choices of communication protocols in the industry today. NetWare servers and workstations typically use the IPX (Internet Packet Exchange) communication protocol. NetWare 4.x servers and workstations also can use other protocols such as TCP/IP for communication.
Figure 1.9 Workstation network components.
STUDY NOTE: Logging in to a NetWare 4.x network is accomplished by the following:
- Network client software
- NetWare Requester
- Communication protocols
- Network Interface Card (NIC) driver
Figure 1.10 shows workstation network components in relationship to the OSI model. The OSI model serves as a useful yardstick for comparing networking components. As you can see from this figure, the OSI model consists of seven layers. The lowest layer--the physical layer--deals with signal propagation. Data bits are suitably encoded using signaling techniques so that you can recover them at the end. The cable connections (MDI: "media dependent interface") and the signaling mechanism are part of the NIC of the workstation and correspond to OSI layer 1. OSI layer 1, therefore, is implemented by the NIC.
Figure 1.10 Network components and the OSI model.
Layer 2 of the OSI model is called the data link layer; it deals with the grouping of bits to form a frame that is sent across the network. The data link layer manages the link between two network nodes. In the case of LANs, link management is implemented by media access control (MAC) techniques such as CSMA/CD for Ethernet and Token Access for token-ring networks. The data link layer function is handled by the NIC.
Layer 3 of the OSI model is called the network layer and deals with routing of packets on a network. In a simple LAN, there might be only one possible route between two network nodes. In more complex topologies, consisting of separate LAN segments connected via a router, multiple paths to a given destination may exist. The network layer figures out the best path to a destination.
Layer 4 of the OSI model is called the transport layer and deals with end-to-end data integrity. It is the job of this layer to ensure that data is sent reliably across the network. If packets are corrupted in transmission (because of noise and equipment malfunction) or arrive in the wrong order at the destination, the transport layer performs the necessary retransmission and proper ordering of packets to make the data stream reliable. In NetWare, the Sequence Packet Exchange (SPX) protocol is an example of a transport protocol that provides this reliability. Readers interested in more details on IPX/SPX can refer to NetWare: The Professional Reference from New Riders Publishing.
Layer 5 of the OSI model is called the session layer and deals primarily with session management. Layer 6 of the OSI model is called the presentation layer and deals with ways data are represented.
Layer 7 of the OSI model is called the application layer and deals with communication Application Programming Interfaces (APIs). The primary protocol NetWare uses at this layer is the NetWare Core Protocol (NCP). This protocol implements the NetWare core services for file, printer, and shared resource access. NetWare 4.x has extended the definitions of the NCP protocol to provide access to additional resource types and functions for NetWare 4.x.
The interface between layer 2 and layer 3 of the OSI model is provided by the network driver. The network driver understands the details of the NIC hardware and its parameter settings (interrupt request, I/O base address, and memory base address).
The network driver is written to Novell's Open Data Link Interface (ODI) specification. The ODI interface is discussed next.
The ODI specification enables a large number of network adapters to support different protocol stacks such as TCP/IP, OSI, SPX/IPX, and AppleTalk. Prior to ODI and similar mechanisms (NDIS and Packet Driver), a separate driver had to be written for each protocol stack; moreover, it was difficult to get these separate drivers to coexist on a workstation, making it hard to support more than one protocol stack.
STUDY NOTE: The ODI specification
- enables network devices that use different protocols to coexist and share the same physi- cal network.
- enables multiple protocols to share the same etwork adapter and cabling system.
- enables a network adapter driver to be written just once for different types of communication protocols.
The two key components of ODI layers are the Link Support Layer (LSL) and the Multiple Link Interface Driver (MLID). These components are shown in figure 1.11.
Figure 1.11 ODI components versus the OSI model.
The Link Support Layer provides an ODI interface to the communication protocol. This interface enables multiple protocol stacks to coexist in harmony and even share the same network board driver. The ODI driver is also called the Multiple Link Interface Driver (MLID) because it can support multiple interfaces to communication protocols via the Link Support Layer.
STUDY NOTE: The key components of ODI are as follows:
- Link Support Layer (LSL)
- Multiple Link Interface Driver (MLID)
In figure 1.11, the Ethernet, Token Ring, and ARCnet networking technologies correspond to layers 2 and 1 of the OSI model. NE2000.COM, TOKEN.COM, and RXNET.COM are the names of the MLID drivers. Other types of boards have different names. These drivers correspond to a portion of the data link layer and are written to interface with the Link Support Layer. The LSL does not map well onto the OSI model but represents the boundary between the data link layer and the network layer.
Because it provides the interface between MLID drivers and the upper-layer protocols, you can think of the Link Support Layer in terms of describing a portion of the data link layer and the lower portion of the network layer of the OSI model. The Link Support Layer is a key element in the ODI specification, providing a logical view of the network adapter and virtualizing it. The network layer software does not have to be rewritten to understand the low-level mechanics and operational details of a new network adapter. The network layer software sees a well-defined virtual interface to any network adapter.
STUDY NOTE: The Link Support Layer
- acts as a switchboard to route packets to the correct protocol and correct ODI driver.
- implements the ODI specification.
The practical significance of the Link Support Layer is that the network layer protocol needs to be written only once to the ODI interface. When a new type of network adapter is built, the manufacturer writes an MLID driver for it that can hook into the LSL. The LSL provides the same logical interface to this board, and the protocol software does not need to be rewritten for the new network adapter.
The same MLID driver can support new types of protocol software as long as the protocols are written to the interface provided by LSL. The MLID driver is able to handle packets from different protocol stacks delivered to it by the LSL. After receiving the different protocol packets from the network, MLID forwards the packet to the LSL without interpreting the packet contents. The LSL is responsible for sending the packets to the correct protocol stack.
STUDY NOTE: The MLID drivers are network adapter drivers that support the ODI specification. They can communicate with the Link Support Layer and are also called ODI drivers.Configuration information for the ODI driver is kept in the NET.CFG file under the Link Driver section.
STUDY NOTE: The ODI driver provides communications between the workstation software and the physical network components.
The configuration information for the MLID driver and protocol modules (IPXODI and TCP/IP) is kept in the NET.CFG file.
The LSL acts as a software switch, through which multiple protocol packet types travel and are delivered to the correct MLID or the correct protocol stack. In order to provide this routing, the LSL contains information about the MLIDs and the protocol stacks they support.
Then the MLID loads, and the LSL assigns a logical number to each network adapter. When a protocol stack loads and registers with the LSL, it is also assigned a logical protocol stack number. The LSL can support up to 16 protocol stacks.
The LSL module is specific to an operating system platform. This means that although LSL is available for DOS, OS/2, NetWare 3.x, NetWare external routers, and so forth, the actual LSL module cannot be interchanged between the operating systems. In DOS, for instance, LSL is loaded as a TSR (terminate-and-stay-resident) program and is implemented in the file LSL.COM; in OS/2 it is loaded as a device driver called LSL.SYS.
STUDY NOTE: The default Ethernet frame type for NetWare 4.x is ETHERNET_802.2 and is specified in the Link Driver section of the NET.CFG file.
Once the LSL module and the MLID drivers are loaded in memory, you can load the protocol modules. The native IPX/SPX protocol used with NetWare is implemented by the IPXODI.COM TSR program.
Figure 1.12 shows different protocol modules loaded at a workstation using the common LSL and an MLID.
Figure 1.12 Multiple protocol stacks using MLID.
STUDY NOTE: Benefits of using ODI include the following:
- Flexible configuration using the NET.CFG configuration file.
- Sharing of the same NIC by different protocols means fewer NICs and less hardware.
- The MLID needs to be written only once for an IC, after which time you can use for commu- ications any board that has the ODI interface.
- Multiple protocol support enables your work- station to communicate with different hosts using the protocols supported by the hosts.
Figure 1.13 shows the files that implement the different workstation components, and figure 1.14 shows ways that the network components and DOS interact. When a request is made for a network or DOS service, it is first seen by DOS. DOS then makes use of its redirection capabilities (introduced in DOS 3.1 and above) to send network requests to the VLM manager. Requests for local resources are handled by DOS itself.
Figure 1.13 NetWare 4.x DOS workstation connection components.
Figure 1.14 NetWare DOS Requester and DOS.
To connect a DOS workstation to a NetWare 4.x network, you need to perform the following steps:
AUTHOR'S NOTE: The VLMs replace the NetWare shell (NETX.COM or NETX.EXE) that was used in earlier versions of NetWare. The VLMs cannot coexist with the older shell's NETX.COM or NETX.EXE.
STUDY NOTE: The CONFIG.SYS file must have the LASTDRIVE=Z statement for NetWare 4.x DOS workstations.
You might find it more convenient to place the commands listed in the preceding steps in a batch file to provide a network connection. This is done automatically when the DOS client software is installed using the DOS client INSTALL program. At the end of running the DOS client INSTALL program, a batch file called STARTNET.BAT is placed in the default directory \NWCLIENT on the workstation's hard disk. An entry is also placed in the startup AUTOEXEC.BAT file that calls the STARTNET.BAT file.
STUDY NOTE: The load sequence for loading network client software at a DOS workstation is as follows:1. Load LSL.COM.
2. Load the MLID (ODI driver) for the NIC being used.
3. Load IPXODI.COM.
4. Load VLM.EXE.
An example of a STARTNET.BAT file for a XIRCOM PCMCIA Ethernet card is shown here:
@ECHO OFF C: CD \NWCLIENT SET NWLANGUAGE=ENGLISH LSL CEODI IPXODI VLM CD \
The STARTNET.BAT batch file is called using a call statement in the AUTOEXEC.BAT file:
@CALL C:\NWCLIENT\STARTNET.BAT
PRACTICAL TIP: The CALL statement to the STARTNET.BAT file is placed in the beginning of the AUTOEXEC.BAT file. The CALL statement usually comes before the DOS PATH statement in the AUTOEXEC.BAT file that sets the local search drives. Some people modify the STARTNET.BAT file to change their directories to the first network drive and to issue the LOGIN command to log in to the network. This action can result in the PATH statement in the AUTOEXEC.BAT file executing after the user has logged in.As a result of this procedure, the network search drives are replaced by the local search drives. To prevent this situation from occurring, move the call to the STARTNET.BAT to the end of the AUTOEXEC.BAT file, or at least after the PATH statement in the AUTOEXEC.BAT file.
STUDY NOTE: The DOS client installation software can add the line
@CALL C:\NWCLIENT\STARTNET.BAT
in the AUTOEXEC.BAT file to automate connection to a network.
When an application makes a request for services, DOS examines this request. If the request is for local network resources, the request is handled by DOS. If the request is for network resources, the request is sent to the DOS Requester. Beginning with DOS 3.1, DOS has had the capability of providing redirection services. The DOS Requester for NetWare (also called the NetWare DOS Requester) shares system tables, such as the drive table, with DOS (see fig. 1.15). DOS keeps track of which drive letter entries in the table are for DOS and which are for the DOS Requester. When an application makes a request for a file on a particular drive letter, after consulting the shared drive table, DOS is able to direct the request to the DOS Requester or local DOS system services.
Figure 1.15 DOS Requester and DOS drive tables.
STUDY NOTE: The NetWare DOS Requester logically resides between workstation software and network services and enables communications between them.
The DOS Requester takes the application request and translates it into an equivalent NCP (NetWare Core Protocol) request. The NCP is used to carry requests for services to a NetWare file server. The NetWare file servers have an NCP server process that can handle multiple requests for network services and send the results of processing the NCP requests back to the sender. The NCP requests are then carried across the network by a transport communication protocol. The default communication protocol for a NetWare client is IPX (Internetwork Packet Exchange protocol).
[BBEG]STUDY NOTE: In NetWare 4.x
- the request for a network service is first seen by DOS.
- DOS and the NetWare DOS Requester share a common drive table.
STUDY NOTE: Application requests for network services are translated into NCP requests for services. The default communication protocol used for sending NCP requests is IPX.
The DOS Requester is implemented by Virtual Loadable Modules (VLMs). VLMs are a way of breaking up the monolithic NetWare shell (NETX.COM or NETX.EXE) found in earlier versions of NetWare into smaller components, each of which you can selectively load.
The communication protocol is implemented by TSR programs. The default IPX protocol is implemented by the IPXODI.COM program.
Though the name of the file makes no mention of the SPX (Sequenced Packet Exchange) protocol, the IPXODI.COM includes the SPX protocol. The SPX protocol is not normally used by NetWare 4.x. It is used in applications such as RCONSOLE (Remote Console) and for establishing connections between print servers and remote printers. These applications require a reliable virtual-circuit connection, which is implemented using the SPX protocol.
You can obtain help on the IPXODI options by typing the IPXODI /? command as shown here:
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
C:\NWCLIENT> IPXODI ?
NetWare IPX/SPX Protocol v3.01 (941031)
(c) Copyright 1990-1994 Novell, Inc. All Rights Reserved.
Available command line options:
/? Display this help screen.
/D Eliminate Diagnostic Responder - Reduces size by 3K.
/A Eliminate Diagnostic Responder and SPX - Reduces size by 9K.
/C=[path\]filename.ext
Specify a configuration file to use (Default is NET.CFG).
/U Unload resident IPXODI from memory.
/F Forcibly unload resident IPXODI from memory, regardless of programs loaded above it. Using this option can cause a machine to crash if applications are still using IPX/SPX.
As you can see from the preceding help message, if the diagnostic responder used by some management programs to collect information on NIC statistics is not needed, using the /D option can reduce memory requirements by 3 KB. Using the /A option eliminates the diagnostic responder and SPX (not used for NetWare core services), which reduces memory requirements by 9 KB.
PRACTICAL TIP: If you are using RCONSOLE or a remote printer at the workstation, you should not use the /A option with IPXODI.
The Link Support Layer is implemented using LSL.COM for DOS. Like IPXODI.COM, the LSL.COM program is also a TSR. It must be loaded before loading the ODI driver. You can obtain the following LSL options by using the LSL ? command:
C:\NWCLIENT> LSL ?
NetWare IPX/SPX Protocol v3.01 (941031)
(c) Copyright 1990-1994 Novell, Inc. All Rights Reserved.
Available command line options:
/? Display this help screen.
/D Eliminate Diagnostic Responder - Reduces size by 3K.
/A Eliminate Diagnostic Responder and SPX - Reduces size by 9K.
/C=[path\]filename.ext
Specify a configuration file to use (Default is NET.CFG).
/U Unload resident IPXODI from memory.
/F Forcibly unload resident IPXODI from memory, regardless of programs loaded above it. Using this option can cause a machine to crash if applications are still using IPX/SPX.
The NetWare DOS Requester consists of a Manager program called VLM.EXE, which upon loading loads the Virtual Loadable Modules (VLMs). VLMs are readily identified by a VLM extension and are program files that provide a specific function.
STUDY NOTE: NetWare DOS Requester consists of two major components:
- Virtual Loadable Modules (VLMs)
- VLM Manager
VLMs provide the same flexibility at the workstation that NetWare Loadable Modules (NLMs) provide at the server. NLMs are software modules that you can load on the server and dynamically link to perform a desired function. Similarly, VLMs are software modules that are loaded at the workstation to provide a desired function. Figure 1.16 shows a comparison of VLMs and NLMs. Novell has specified ways to write NLMs, and many third-party vendors provide management capabilities and applications that you can connect directly to internal NetWare resources, with the NLM acting as an extension of the operating system. As the use of VLMs becomes more popular, third-party products that extend the workstation's network capability will increase. As new VLMs become available, they can connect to the VLM-bus in figure 1.16 and provide a clean way of extending the capability of the network client software.
Figure 1.16 The VLM-bus versus the NLM-bus.
STUDY NOTE: When VLM.EXE loads, it loads and activates the NetWare DOS requester.
The VLM Manager, implemented by VLM.EXE, is a TSR and can manage VLM program files written to the VLM specification.
The data flow and communications between VLMs are managed by the VLM manager. The VLM manager is also responsible for handling application requests and forwarding them to the appropriate VLM that can process the request. It also manages memory services on behalf of the VLMs, such as a VLM's need for memory allocation and deallocation.
STUDY NOTE: The VLM Manager is responsible for the following:
- Managing data flow and communications between VLMs
- Forwarding application requests to the appro- priate VLM for processing
- Controlling VLM access to memory at the workstation
After the VLM Manager loads, the VLM program files (those with a VLM extension) are loaded in a default order if the USE DEFAULT=ON option is specified in the NET.CFG file's NetWare DOS Requester section. The NET.CFG is a configuration file that is used by the workstation communication software.
If USE DEFAULT=ON is not specified, the VLMs are loaded in an order that must be specified in the NET.CFG file.
The VLM Manager will look for VLMs in the current directory. If you want to load VLMs from another directory, you can use the /C=directory option to specify an alternate directory. You can also specify an alternate NET.CFG. The only way to get the VLMs themselves from outside the current directory is to specify the full path on the VLM= line in NET.CFG.
STUDY NOTE: Some benefits of using VLMs include the following:
- Only needed components are loaded. This reduces workstation memory overhead.
- Because the requester consists of a smaller umber of components, each of these compo- ents has a better chance of being loaded in upper memory (memory between 640 KB and 1 MB) than if it was one large module.
- Using VLMs opens up the workstation archi - tecture for development by third parties who can write additional VLM components.
The VLM Manager has a number of options, including using expanded, extended, or conventional memory; using alternate configuration files; and unloading the VLM TSR program without rebooting the workstation. You can see these options by typing this command:
VLM /?
The following output shows the help messages for the different VLM options:
){kind=link}
C:\NWCLIENT> VLM /?
VLM.EXE - NetWare virtual loadable module manager v1.20 (941108)
(c) Copyright 1994 Novell, Inc. All Rights Reserved.
Patent pending.
Available command line options:
/? Display this help screen.
/U Unload the VLM.EXE file from memory
/C=[path\]filename.ext
Specify a configuration file to use (Default is NET.CFG).
/Mx The memory type the VLM.EXE file uses where x is one of the following:
C = Conventional memory.
X = Extended memory (XMS).
E = Expanded memory (EMS).
/D Display the VLM.EXE file diagnostics.
/PS=<server name>
Preferred server name to attach to during load.
/PT=<tree name>
Preferred tree name to attach to during load.
/Vx The detail level of message display where x is one of the following:
0 = Display copyright and critical errors only.
1 = Also display warning messages.
2 = Also display VLM module names.
3 = Also display configuration file parameters.
4 = Also display diagnostics messages.
The more important of these options are summarized in table 1.2.
| VLM Command | Description |
| VLM /C=[path\]filename | Loads DOS Requester using the configuration file's filename instead of the default NET.CFG. |
| VLM /MC | Loads DOS Requester in conventional memory. |
| VLM /ME | Loads DOS Requester in expanded (EMS) memory. |
| VLM /MX | Loads DOS Requester in extended (XMS) memory. |
| VLM | Loads DOS Requester. VLMs loaded are those in the current directory or those specified in the NET.CFG file. |
The VLM.EXE program automatically selects the best possible memory use: extended memory first (if extended memory drivers are loaded), expanded memory second (if expanded memory drivers are loaded), and conventional memory only in the absence of enhanced memory options.
STUDY NOTE: Study the options in table 1.2 .
Figure 1.17 shows the steps necessary to log in to the network. After the VLM Manager loads, it searches for the nearest active server. A connection between the workstation and the server is established, and the first network drive is mapped according to the FIRST NETWORK DRIVE statement in the NetWare DOS Requester section of the NET.CFG file. This is usually set to drive F: (see fig 1.17). The first network drive is mapped to the SYS:LOGIN directory of a server volume. The phrase "mapping a drive" means that the DOS workstation can access the remote file system SYS:LOGIN by using the same DOS commands that are used to access a local drive, such as drive C:. A sample NET.CFG file, used for connecting to a NetWare 4.x network, is shown next.
Figure 1.17 Logging in to the network.
Link Driver CEODI FRAME Ethernet_802.2 INT 5 PORT 380 MEM d0000 IOWORDSIZE 16 NetWare DOS Requester FIRST NETWORK DRIVE = F
NET.CFG has a number of section headings. In this example of the NET.CFG file, the section headings are Link Driver CEODI and Net-Ware DOS Requester. The section headings always begin in the first column of the file. Under the section heading are configuration statements that pertain to that section. These statements are indented by at least one character or a tab. The statements in the Link Driver section deal with the driver configuration, and the statements under the NetWare DOS Requester are for the VLM.EXE.
STUDY NOTE: After VLM loads, it maps as a network drive the drive specified in the FIRST NETWORK DRIVE statement in NET.CFG.
At this point, changing your current drive to the F: drive makes the programs in that drive (SYS:LOGIN directory) accessible. One of the programs in the F: drive is LOGIN.EXE. When the program LOGIN.EXE is run, it prompts for the user name and password. If these are entered correctly, the user is logged in to the user account on the network. Thus, the steps to complete the login process are as follows:
F: LOGIN Enter your user name: username Enter your password: secretpassword
STUDY NOTE: Executing LOGIN.EXE from the mapped network drive activates the login procedure.
Login is the mechanism or procedure that requires you to identify yourself in order to gain access to the network resources that network security permits you to access.
There are currently 13 VLMs that are loaded if the USE DEFAULT=ON option is specified in the NetWare DOS Requester section of the NET.CFG file. For a NetWare 4.x client enabled for directory services, the order in which the VLMs are loaded reflects the order in which they are used. If you do not want to load a VLM, you can delete it or rename it. PNW.VLM, for example, is used to support Personal NetWare. If you are not using Personal NetWare, you can delete or rename the PNW.VLM file.
The default load order is listed here:
2. IPXNCP.VLM
3. TRAN.VLM
4. SECURITY.VLM
5. NDS.VLM
6. BIND.VLM
7. PNW.VLM
8. NWP.VLM
9. FIO.VLM
10. GENERAL.VLM
11. REDIR.VLM
12. PRINT.VLM
13. NETX.VLM
Table 1.3 provides a description of the VLM functions. The list is not exhaustive; it lists only the important VLMs that are within the scope of this book.
Table 1.3 VLM Table Summary of the Major VLM
| VLM Name | Brief Description |
| BIND.VLM | Bindery emulation--child of NWP.VLM |
| CONN.VLM | Connection table manager |
| FIO.VLM | File input/output for network requests |
| GENERAL.VLM | Provides miscellaneous functions for other VLMs such as NETX.VLM and REDIR.VLM |
| IPXNCP.VLM | Transport Protocol Processing using IPX--child of TRAN.VLM |
| NDS.VLM | NetWare Directory Services--child of NWP.VLM |
| NETX.VLM | Shell compatibility |
| NWP.VLM | NetWare Protocol Multiplexor |
| PNW.VLM | Personal NetWare VLM |
| PRINT.VLM | Print redirector |
| REDIR.VLM | Redirector |
| RSA.VLM | Background authentication service |
| TRAN.VLM | Transport protocol multiplexor |
Now that you have learned to log in to the network, what kind of network tasks can you perform? This section gives you a guided tour of some basic NetWare utilities.
NetWare 4.x provides for the following basic utilities:
NetWare graphical user interface utilities are available for MS Windows and OS/2. These utilities are bundled with NetWare 4.x and are installed when the server is installed. If you are familiar with MS Windows-based applications, you will feel at home using these utilities. The NetWare graphical user interface utilities include programs such as the following:
Figure 1.18 shows the top level screen for the NWUSER utility.
Figure 1.18 The NWUSER screen.
You are now presented with a guided tour for using the NWUSER utility.
Throughout this guided tour and others dealing with GUI utilities, the following terms will be used. If you have never used MS Windows, these terms may be helpful to you.
Left click on X Position the mouse pointer on X and click the left button of the mouse once. Click on X Same as left click on X. Double click on X Position the mouse pointer on X and click the left button twice in rapid succession. Right click on X Position the mouse pointer on X and click the right button of the mouse once.
To open the NWUSER utility, follow these steps:
Figure 1.19 The MS Windows startup screen.
Figure 1.20 The NetWare group program items.
Figure 1.21 NetWare Drive Connections. For sending messages, perform the following steps:
To send a message to a group of users, follow these steps:
To create a network drive mapping, you can assign a network drive to a directory on a server volume:
Figure 1.22 The NetWare Drive Connections screen.
Figure 1.23 The NetWare Drive Connections screen.
Figure 1.24 New drive mapping created. Practice deleting the drive mapping you just created by performing the following steps:
STUDY NOTE: You can create a drive mapping by dragging a directory from the right panel and dropping it on top of a network drive in the left panel of the screen. To remove a drive mapping, you can highlight the drive mapping and drag it away from the left panel.
Using the Login and Logout options, you can log out and log back in from within the NetWare User Utility:
Examine the NetWare settings:
Figure 1.25 The NetWare Settings dialog box.
NetWare DynaText is a graphical utility that works with Windows 3.1 (or higher) to make online manuals accessible through a graphical user interface (GUI). Figure 1.26 shows a sample DynaText screen.
Figure 1.26 A Sample DynaText screen.
All the NetWare manuals are available in DynaText format. A list of these manuals and a brief description of their contents follows:
This index links to all places in the manuals. Click on a link marker to go to a place in the manual in which a term or topic can be found.
This reference provides the information you need to understand the AppleTalk protocol stack for NetWare servers. It describes configuration parameters for the AppleTalk protocol stack.
Btrieve is a popular and efficient record manager bundled as an NLM in NetWare servers. This manual contains information on installing, configuring, executing, and monitoring the Btrieve record management system for NetWare servers.
This is a glossary of NetWare-related terms with a tutorial description of what each term means. Topics are listed alphabetically in categories ranging from AAA to ZZZ.
This manual helps you set up and install your client software. It introduces you to the client tools for managing your client on a NetWare network. The manual covers concepts and procedures for installing and using NetWare client software on NetWare 2.x, 3.x, and 4.x networks.
This manual describes the parameters needed to configure NetWare workstation software on NetWare 2.x, 3.x, and 4.x networks.
This contains information on how to install a new NetWare 4.x server.
This manual provides the information you need to understand the IPX protocol for the router. It describes the IPX configuration parameters.
This manual explains how to install, configure, and maintain the NetWare for Macintosh software.
This manual describes the NetWare for Macintosh MacNDS client software. The MacNDS client software enables access to NetWare 4 NDS services from Macintosh workstations.
This manual explains the NetWare MHS (Message Handling Service) services, and explains how to install and manage it. The guide also describes how to use the FirstMail client software.
This manual explains how to install and use the NetSync utility. NetSync is a management utility that enables you to manage NetWare 3.x servers from the NetWare Directory Services.
This manual introduces you to the basics of NDS and helps you plan the NDS tree.
This manual introduces you to features that are unique to NetWare 4.x.
This manual describes the installation and configuration of NetWare Client software for OS/2 workstations. This client software can be used for both NetWare 3.x and NetWare 4.x. The manual contains information on accessing network services form Virtual DOS machines and setting up Named Pipes and NetBIOS protocol support.
This helps you with NetWare 4.x printing concepts and how you can set up, load, and use network printing utilities. It contains some troubleshooting tips and guidelines for network print services.
This helps you to set up and administer the network after you complete the NetWare 4.x installation. It covers issues such as managing NDS, NetWare files and directories, creating login scripts, NetWare server maintenance, network auditing, and backing up and restoring data.
This contains information on how to use NetWare utilities, such as Text workstation utilities, server utilities, and GUI-based utilities. It also contains information on NDS bindery objects and their properties.
This manual describes upgrading to NetWare 4.x from other NetWare servers, such as NetWare 2.x or 3.x and IBM LAN Server.
TCP/IP is a de facto protocol for connecting heterogeneous systems together. This manual discusses how TCP/IP can be configured and managed on the NetWare 4.x server. It explains the concepts in relationship to NetWare's implementation of TCP/IP.
This describes an overview of the security requirements for large networks and how NetWare 4 auditing can be used to meet these requirements.
This is a list of all possible system and warning messages that you may encounter in configuring NetWare 4.x. It lists the messages according to the modules that generate them, and there are over 150 modules. It explains the possible cause of the error message and the action you can perform to fix it.
The online documentation can be viewed using DynaText. The following is an outline of the procedure for using DynaText:
Figure 1.27 The opening DynaText screen.
Figure 1.28 The Concepts manual screen.
The DOS text-based utilities are utilities that use the extended character set, such as line drawing characters. Figure 1.29 shows an example of the NETUSER menu-based tool. These tools are based on a modified C-Worthy utility library.
Figure 1.29 The NETUSER main screen.
The following are examples of other menu-based text utilities:
The text utilities make use of the special control keys shown in table 1.4.
Table 1.4 Text Utility Control Keys
| Key | Action |
| Up/Down arrow keys | Move between menu choices |
| Enter | Selects menu option |
| Esc | Goes back to previous menu |
| F1 | Obtains help |
| F3 | Modifies an option |
| F5 | Marks an option |
| F10 | Saves changes and continues |
| Alt+F10 | Exits menu |
| Ins | Adds item to list |
| Del | Deletes item from list |
You will now be presented with a guided tour of using the text-based utility, NETUSER. NETUSER provides many of the capabilities of the NetWare User Utility from a menu-driven text utility.
Throughout this guided tour and other guided tours dealing with text-based utilities, the following terms will be used: Select option X from Y Use the up/down arrow keys to highlight X from menu with title Y and press the Enter key. Mark option X Highlight option X and press the function key F5.
To send a message to another user, follow these steps:
Figure 1.30 Messages option in NETUSER.
Figure 1.31 The Send Messages option in NETUSER.
6. Type a message in the message area on the bottom half of the screen.
7. Press Enter to send the message.
8. If you want to clear a message that you receive from another user, press Ctrl+Enter.
To send a message to a group of users, follow these steps:
Figure 1.32 Checking receive message status.
What is the current status of "Receive message"? (Look for the gray box on the top half of the screen.)
Figure 1.33 Setting Message options to not receive messages.
Figure 1.34 The Current Drive Mappings screen.
Figure 1.35 Select Directory in NETUSER.
Select the option Attachments from the main NETUSER screen:
Figure 1.36 Newly created drive.
NetWare command-line utilities are executed at the shell command prompt. These utilities are located in the SYS:PUBLIC and SYS:SYSTEM directories. Their general syntax is as shown here:
COMMAND_NAME [Parameters] [/Options]
Examples of some of these utilities are as follows.
To list information on users currently logged in, use
NLIST USER /A
To send message to users who must be logged in, use
SEND "message" to user
To obtain help on commands NLIST and SEND, use
NLIST /? SEND /?
Figures 1.37 and 1.38 show help on the SEND command.
Figure 1.37 SEND /? Help--Screen 1.
Figure 1.38 SEND /? Help--Screen 2.
Table 1.5 shows the important options for the SEND commands.
Table 1.5 Important SEND Commands and Options
| SEND Command | Description |
| SEND /A=N | Accept no messages (including console messages). |
| SEND /A=C | Accept only console messages. |
| SEND /A or SEND /A=A | Accept all messages. |
| SEND "message" | Send message to login name.to loginname |
| SEND "message" | Send message to group name.to groupname |
The command-line utilities have a /? switch that gives additional help information on ways to use these utilities. This switch is very convenient, because help is available from the command line without invoking any other online documentation. Typing illegal command-line parameters also results in help screens being displayed. You can see the NDIR help screen by using the following command:
>NDIR /?
Help is also available in the menu utilities via function key F1. This help is context-sensitive. The menu utilities such as FILER and PCONSOLE use the familiar C-Worthy Menu interface. Unlike previous versions of NetWare, using the F1 key twice (F1,F1) does not display extended help information.
NetWare 4.x online help is available through the DynaText application that runs under Windows. DynaText is a valuable tool for quickly looking up information on a topic.
You have seen ways that a workstation makes a network connection in a NetWare 4.x network. After you are logged in, NetWare 4.x provides you with a number of useful features. This section provides you with an overall understanding of these features and capabilities.
NetWare 4.x features include the following:
In pre-NetWare 4.0, the network management tasks had to be performed separately on each NetWare server, because network management usually resulted in a modification of the bindery, and the bindery was specific to each server. To perform network management tasks, the bindery (a local database of network resources on a specific server) had to be modified on each server.
Because the NDS is a global database, global network management is possible where the network administrator can administer the network resources from any place on the network (see fig. 1.39). Also, as you will learn later, the network administrator can delegate responsibility to other users who serve as network administrators. In pre-NetWare 4.0, the responsibility was delegated to a fixed number of user account managers, workgroup managers, and other operators; in NetWare 4.x, many levels of network administrators with varying degrees of responsibilities can exist.
In pre-NetWare 4.0-based networks, the resources were described in a server bindery and were dependent on that server. A classic example of this was NetWare printer definitions that were tied to a specific server. If the printer had to be relocated to another server, the bindery representation of the printer had to be moved to another server (see fig. 1.40). In a large network that is in a state of flux, this shuffle can become a major task.
Figure 1.39 Global network management.
Figure 1.40 Bindery representations of printer definitions.
In NetWare 4.x, the resource definitions are not tied to any specific server or a physical location on the network. This means that a user can access a resource without worrying about the physical location of the resource and ways to reach it. Changes to network resources are made to the NDS objects that are part of a global database. The user can access the NDS object from any station on the network, provided he or she has been granted security permission for the resource.
One of the strengths of NetWare has always been a fast and efficient file system. This has always been central to NetWare's popularity and ability to act as a file server. In NetWare 4.x, the file system has been improved. Some of these improvements are the result of new features called block suballocation, compression, and migration.
NetWare 4.x enables the disk block size selected at installation time to be 4, 8, 16, 32, or 64 KB (where 1 KB is 1024 bytes). This capability also existed in NetWare 3.x. However, in NetWare 3.x, if a 200-byte file was created on a volume that had a disk block size of 4 KB, a 4 KB block of storage would be allocated and the remaining 3,896 (4,096 - 200) bytes would not be available for use. This represents a wasted space of 95 percent, and if the disk block size was 64 KB, the wasted space would be even greater. Figure 1.41 shows how block suballocation in NetWare 4.x works.
Figure 1.41 Block suballocation.
In NetWare 4.x, the unused disk block space is used in 512-byte suballocation units. This means that in the example of creating a 200-byte file, a 512-byte suballocation within the 4 KB disk block would be used. The remaining seven 512-byte suballocation blocks would be available for sharing by the leftover fragments of other files. If all these suballocation blocks were used, in the NetWare 4.x example there would be wasted space of only 312 (512 - 200) bytes out of a total of 4,096 bytes--only 8 percent wasted space. Also, if the file sizes and leftover fragments were multiples of 512 bytes, there would be no wasted space.
STUDY NOTE: Understand how block suballocation works in terms of how many suballocation units are used for a file of a given size.
You can define block suballocation as a mechanism in NetWare 4.x that enables small files and files that are not multiples of the disk block size to share space in a disk block that would otherwise go to waste. The improved utilization in disk space is accompanied by the extra overhead in the operating system to maintain the status of disk blocks that have been suballocated, but because caching is used, the impact of this overhead is minimal.
Disk suballocation is enabled by default during a NetWare volume's installation. You can explicitly disable it during installation.
TIP: Always allocate a disk block size of 64 KB for maximum gain in server disk performance, because the software and disk subsystems perform at an optimum at this block size.
Studies have shown that the processor utilization of many NetWare servers in real life networks does not often exceed 50 percent. In heavily loaded servers, it is not uncommon to see processor utilization higher than 90 percent, but such situations are relatively rare for servers that are predominantly being used for file and print services. The designers of NetWare 4.x decided to use this unutilized processor bandwidth for useful background tasks such as file system compression. Today there are many disk compression utilities available for DOS. However, these utilities decompress disk blocks as they are read and recompress when they are written. This process causes the disk to appear slow because of the compression operation that accompanies each read or write operation.
In NetWare 4.x, file compression is performed in the background. You can set certain parameters at the file server to control the frequency at which compression can be performed in the background. When a file is retrieved, it is decompressed. The file blocks that are immediately decompressed are available for use, even as the rest of the file is being decompressed by special decompression threads (see fig. 1.42). Usually, the file remains in the decompressed state for a certain period of time that is controllable at the server. You also can control the status of the compressed file--whether it should be left in the compressed state or decompressed state after it has been accessed. The compression of files is always performed in the background.
Figure 1.42 Read of a compressed file.
By using the file compression feature, you can increase effective disk space without adding new server drives. The amount of savings in disk space depends on the nature of repeated characters or binary patterns in the file and is very high for text files. It is not uncommon to see savings of 63 percent or more because of file compression. This means that 500 MB of files can take up as little as 185 MB (at 63 percent compression) of disk space. With disk space being at a perennial premium on file servers, this is a great advantage.
A file is not compressed unless NetWare sees a certain gain in disk space. The network administrator can exercise explicit control by flagging files and directories for immediate compression or never to be compressed. The network administrator can exercise control of compression using SET commands from the server console.
You can enable or disable the compression option during instal-lation of a volume on the NetWare server. The default is that compression is enabled, which means that NetWare will try to compress a file if it has not been used for some time, as long as a minimum savings in disk space is possible.
Data migration enables infrequently used files to be moved to a near-line or off-line storage medium. Examples of near-line storage are optical disk libraries (also known as jukeboxes), and examples of off-line storage are tape backup devices. When data migration occurs, NetWare 4.x still sees the data on the NetWare volumes, because the directory entries for the migrated files are still on the NetWare volume. If a file is accessed and it has been migrated, the file is brought back (de-migrated) to the NetWare volume (see fig. 1.43). The net effect of data migration is that valuable disk space is freed up. When combined with compression, data migration is a very effective way of saving disk space.
Figure 1.43 Data migration.
Some of the earlier Control Data Corporation's supercomputers used data migration, but NetWare 4.x is the first one to popularize its use among PC-based network operating systems (NOS).
You can enable and disable data migration when you install the NetWare volume. You can also mark files for migration by using NetWare utilities such as FILER and the FLAG command.
The High Capacity Storage System (HCSS) enables data migration to be implemented. HCSS is a storage and retrieval system that can extend the capacity of a NetWare server by integrating optical libraries into the NetWare file system. HCSS can work in conjunction with data migration, so that you can move migrated files from the faster but lower-capacity NetWare volumes to the slower but higher-capacity media that comprise the HCSS.
As far as the user is concerned, the operation of data migration and HCSS is transparent. Files that have been migrated to HCSS are accessed with the same commands as files that reside on the NetWare volume. If a migrated file is accessed, it is automatically de-migrated.
PRACTICAL TIP: With the help of NDIR, FILER, NWADMIN, or the SERVMAN.NLM, you can ascertain whether a file has been migrated by seeing if its M (migrate) attribute is set.
Migration is performed on an individual file basis depending on the last time the file was accessed, called the least recently used criteria, and the current volume usage. Least recently used criteria for files refers to files that are the least active, or that have not been accessed for the longest time. If the current volume usage exceeds a capacity threshold, data migration occurs. Capacity threshold is defined as the percentage of the server's disk that is used before data migration begins.
Access to the NetWare 4.x-based network is performed when the user logs in to a network's NetWare directory. Each organization has its own network directory tree that reflects the usage and security needs of network users. As part of implementing net-work security, access to parts of the network directory tree are controlled by explicit trustee assignments. Figure 1.44 shows the different steps that must occur before a user is granted access to a file on a volume. These include login authentication, NDS security, and NetWare file system security.
Figure 1.44 NetWare 4.x security.
When a user logs in to the network, the user specifies the name of the NDS object that represents the user account. The user's login name and password are used to build a personalized key that is used to authenticate a user's right to access the network. The actual algorithm that is used to build the personalized key is RSA, which stands for Rivest, Shamir, and Adelman, the original creators of the famous public encryption key algorithm. Novell licensed this technology from RSA, Inc., for use with NetWare 4.x.
When the user is authenticated on the network, the user must have rights to directory objects that represent resources on the network. This is seen in figure 1.44, where a user has to pass through the NDS Security. For example, in order to access files on a volume, the user must have certain rights to the volume object in the directory tree.
After the user is authenticated by the NDS, the user's access to a file is controlled by the File and Directory Trustee rights. These rights are the same as those for the NetWare 3.x servers.
Network management is done by the network administrator. An initial user account called ADMIN is created when a directory tree is first established. This is equivalent to the SUPERVISOR user in pre-NetWare 4.0, except that the ADMIN user has network-wide responsibility. The ADMIN user account can be deleted or renamed; in that sense it does not have any special significance. This contrasts with the SUPERVISOR account in NetWare 3.x and 2.x servers, which could not be renamed or deleted. Because the ADMIN account can be deleted, care should be taken to ensure that other users have the equivalent of supervisory rights to the directory tree before the ADMIN account is deleted.
PRACTICAL TIP: For secure environments, rename the ADMIN account so that an unauthorized user cannot use the supervisor's username to try to break system security.
The ADMIN user can create other user objects anywhere in the directory tree. This is usually done in such a manner that the users can access resources in the directory tree easily for ease in implementing security on the network.
The network administrator can delegate different levels of network responsibility to users, such as the authority to create other user objects but not delete them, or the responsibility of managing part of a directory tree but not accessing the information represented by the objects. This makes it possible to have multiple levels of network administrators in a manner that is more flexible than the NetWare 3.x approach of workgroup managers and user account managers.
You can more finely control security in NetWare 4.x by creating assistant supervisors who can administer network resources but who do not have access to data that needs to be protected from view, such as payroll data or other financial data of an organization. You can implement this control by setting the NDS object rights. Object rights control access to NDS objects in the NDS tree. To control access to information inside the NDS objects, you need another type of object right called the Object Property right.
In NetWare 4.x, you can designate a user as an auditor. The auditor acts independently of the network administrator to audit critical activities on the network. The auditors can also audit past and present transactions on the network for any security breaches (see fig. 1.45). It is important to understand why network auditors need to be independent of the network administrator. The network administrator of the directory tree, unless specifically restricted, has unrestricted access to data and resources on the network. As a result, an organization has to place great trust in the network administrator. If this trust is betrayed, the network administrator can cause a great deal of damage to an organization's data and privacy of data.
Figure 1.45 Auditing in NetWare 4.x.
Auditing enables auditor users to monitor actions on the network, including that of the network administrator. For this reason, an auditor should not have Supervisor rights or Supervisor-equivalent rights. An auditor's main function is to track events on the network, but they are unable to modify data on the network, other than the Audit Data and Audit History files.
Auditing should not be confused with accounting features of earlier NetWare versions. Accounting enables the tracking of resource usage on the networks, such as disk blocks read and written to, storage charges, and service requests. This accounting capability is still available in NetWare 4.x.
Auditing enables the monitoring of critical events on the network such as logins and logouts, file operations, directory services object operations (creations, deletions, reads, and writes), directory object events, user events, and trustee modifications. To audit files, auditing is enabled at the volume level. For directory objects, auditing must be enabled at the container object level. Container objects are used in the NDS tree for organizational purposes and are discussed in the next chapter. When enabled, log files are created to track audited operations.
The primary utility for implementing auditing is AUDITCON, a menu-based text utility.
NetWare 3.x was a great improvement over NetWare 2.2 in the way memory was managed on the server. However, there were a few problems with memory management under NetWare 3.x, as seen in figure 1.46. In NetWare 3.x, memory was managed in five pools, each serving a different purpose. The pools were for purposes such as permanent memory, movable cache, nonmoveable cache, and semi-permanent memory.
Figure 1.46 NetWare 3.x memory management.
As the names suggest, each memory pool served a special purpose. To meet temporary high demands, memory pools were permitted to borrow memory from the file cache buffer memory; but once borrowed, this memory was not returned. Under certain conditions, it was possible for this memory leakage to occur to the point that the file cache buffer memory was severely depleted, and this resulted in a severe degradation in server performance. To reset the memory pools, the server had to be restarted.
In a manner similar to the way NetWare 3.11 was an improvement over NetWare 2.x, NetWare 4.x memory management is a considerable improvement over NetWare 3.11. For one thing, there are no separate memory pools (see fig. 1.47). There is only one main pool and that is the file cache memory. All memory used by processes running on the server is borrowed against this pool and completely returned to it when the process terminates, at which time the returned memory becomes available to other processes. As a result, memory management is simpler because there is only one pool instead of five. Also, because memory management is simpler, it takes fewer processor cycles to accomplish, and memory allocation is therefore faster.
Figure 1.47 NetWare 4.x memory management.
Some of the features of NetWare 4.x memory management include the following:
A controversial aspect of NetWare 3.x memory usage is that all programs--the kernel and applications--run in ring 0 of the Intel 80386 architecture. The Intel 80386 architecture defines 4 rings: rings 0 to 3 (see fig. 1.48). The purpose is to have the operating system kernel run at ring 0, and other programs at one of the outer rings. Programs running at ring 3 can access the RAM used by other programs running in ring 3 but cannot directly access RAM for programs running at rings 2, 1, or 0. If the operating system kernel is running in ring 0, a program at ring 3 would have to make an inter-ring gate call to make service requests from the operating system kernel. If the program crashes, it cannot affect the operating system kernel. This architecture makes the system more reliable at the cost of reduced speed because of the inter-ring call overhead. An example of an operating system that uses the ring architecture is OS/2.
Figure 1.48 Intel 80386 processor ring architecture.
NetWare 3.x does not use the ring architecture. The NetWare 3.x operating system, NLMs, and all server processes run in ring 0. What NetWare 3.x loses in reliability, it gains in simplicity and speed.
In NetWare 4.x, all NLMs by default run in ring 0. However, the network administrator can configure the server to run NLMs that are loaded in an outer ring so that offending programs cannot cause the operating system kernel that runs in ring 0 to crash. As new NLMs are added to the server, you can load them in an outer ring for a trial period. They will run a little slower there because they have to make an inter-ring call. If the NLMs prove to be reliable, you can add them to ring 0, where they can run faster.
PRACTICAL TIP: When purchasing NLMs from third parties, check to see if they are designed to run in an outer ring of the Intel processor (80386 and higher). Not all NLMs can run in an outer ring.
The NetWare 4.x networking software for workstation operating system clients includes better support for DOS, MS Windows, and OS/2 (see fig. 1.49). DOS and MS Windows now use a DOS Requester, ODI support, and Packet Burst Protocol support.
Figure 1.49 Multiple client support in NetWare 4.x.
The DOS Requester enables the redirector capability of later releases of DOS via the interrupt mechanism INT 2F (hex) to be used. The earlier NetWare shell used the DOS INT 21 (hex) mechanism and a software multiplexor mechanism to direct the request to appropriate system services. Because of the additional overhead of the software multiplexor mechanism, it was slightly less efficient. In NetWare 4.x, the DOS Requester actually consists of a number of smaller components that need to be loaded only if the service is needed. These smaller components are called Virtual Loadable Modules (VLMs) and are loaded and managed by the VLM Manager (VLM.EXE). VLMs give you the flexibility of selectively loading only the services that are needed. VLMs are designed to understand NetWare Directory Services, and there is even a VLM component (NETX.VLM) that can be used to communicate with bindery-based servers.
The ODI support is the Open Data Link interface that provides an interface for protocol stacks to talk to network boards that represent layer 2 (the data link layer) of the OSI model. The ODI interface was also available in earlier NetWare client software.
The Packet Burst Protocol enables transmission of multiple packet requests and packet replies. It is similar to the window flow-control mechanism used in other protocol suites and is an improvement over the single-packet request/response behavior of the earlier NCP packet transmissions. The Packet Burst Protocol was added to later releases of NetWare 3.x and is also available for NetWare 4.x.
The Packet Burst Protocol is particularly useful for multiple NCP packet requests and packet replies, where a number of requests or replies can be acknowledged by a single acknowledgment packet. This eliminates some of the overhead of the round-trip delay when a sender has to wait for the last packet that was sent to be acknowledged before transmitting the next packet. It also results in fewer packets being sent, and this results in reduction of network traffic and reduced time for processing packets.
Another enhancement in NetWare 4.x is support for Large Internet Packet (LIP). Earlier NetWare routers were limited in the size of the Internet packet that could be supported. With LIP, this limit has been removed, and the larger packet sizes that are common in token ring networks (4 KB to 16 KB) and Ethernet networks (1.5 KB) are possible.
Storage Management Services (SMS) in NetWare 4.x provide data on the network to be backed or restored in a common data format and in a manner that is hardware- and software-independent. A Target Service Agent (TSA) program is run on each device that needs to be backed up, and it is the target for the backup program. These targets include workstations and NetWare 3.x and 4.x servers (see fig. 1.50).
Figure 1.50 SMS and TSAs.
The SBACKUP program is an example of a program that uses SMS for backup and restore operations. SBACKUP is an NLM that runs on a NetWare server. The NBACKUP functionality of earlier NetWare releases is now consolidated in SBACKUP.
SMS consists of a number of other modules, such as the Storage Management Data Requester (SMDR), that are used to pass commands between SBACKUP and the TSAs. TSAs are device drivers that use the Storage Device Interface (SDI) to communicate between the SBACKUP program and the storage devices (see fig. 1.51).
Figure 1.51 SMS architecture.
PRACTICAL TIP: Besides SBACKUP you may want to consider a number of third-party backup schemes that use SMS. These provide a simpler and streamlined user interface and many advanced backup options.
In NetWare 3.x, print services were defined as part of the print server definition, and the only way to do a network print job was to submit the print job to a print queue. In NetWare 4.x, you can still send the network print jobs to the network print queue, but you can also send print jobs to the printer object in the NDS tree.
Other improvements in NetWare 4.x printing include the following:
Printing issues are covered in greater detail in later chapters.
Because the character of NetWare has become international in scope, NetWare 4.x has introduced support for international languages to NLMs and network utilities. This means that you can set messages and options associated with utilities in the language of the user. The default language is English, but you can add support for other languages during installation.
It is even possible to have different language NLMs running on the server at the same time, or have one user using the system utility NETADMIN in French and another user using the same utility in Italian. It is important to understand that the language support does not mean that NetWare is capable of translating messages between users using different languages. For example, if the SEND utility is used by a French language user to send a message in French to another user who is set up to use Italian, NetWare is not smart enough to translate the message from French to Italian.
Even though the language may be the same, there may be differences in the manner in which dates, times, and numbers are formatted. A classic example of this is English, which is spoken in both the U.S.A. and the U.K. The default format for representing dates in the U.S.A. is mm/dd/yy (for example, 10/16/93). In the U.K., the default date format would be dd/mm/yy (for example, 16/10/93). The formatting is not just dependent on the language but can change across different locales for the same language.
Example of the date, time, and number formats for U.S.A, U.K., France, and Germany are shown in table 1.6.
Table 1.6 Format Differences for Countries
| Country | Number Format | Time Format | Date Format |
| U.S.A. | 355,113.22 | 11:55:00 PM | 10/16/93 |
| U.K. | 355,113.22 | 23:55:00 | 16/10/93 |
| Germany | 355.113,22 | 23:55:00 | 16.10.93 |
| France | 355 113,22 | 23:55:00 | 16.10.93 |
The ability to support differences in language and format representations is called internationalization. Internationalization in NetWare is supported through unicode representation, which is a standard for representing data in 16 bits instead of the familiar 8-bit ASCII.
NetWare 4.x distribution comes in CD-ROM. Distribution on high-density floppy disks is available at an additional cost by sending in the request form that accompanies the NetWare 4.x distribution.
Installing NetWare 4.x on CD-ROM saves time during installation, because the copying of the files from the distribution media is much faster. This leads to a simpler and faster implementation.
You can attach the CD-ROM drive to the server that is being installed, or to a remote workstation. Figure 1.52 shows the different possibilities for CD-ROM configuration. The CD-ROM drive is shown as an external unit to the workstation or server. Internal CD-ROMs are also possible.
Figure 1.52 NetWare 4 installation using CD-ROM distribution.
If you are preparing for the NetWare 4.x Administration exams, review the chapter with the following goals:
In this chapter, you have examined the basic networking components that are used in a NetWare 4.x network. You have learned to configure a DOS workstation to make a connection to the network and log in to the network. You have learned about the different networking components that are used on a DOS workstation and the functions each component performs.
NetWare 4.x represents an exciting change in the way large enterprise-wide area networks are supported. The principal change has been the introduction of NDS. NDS enables you to superimpose a logical structure or view on a physical network, which makes the network easier to use and administer.
Because NDS is central to accessing resources on the network, security is integrated into NDS. When a user logs in, that user is authenticated at the NDS level.
Other improvements to NetWare 4.x have been made in the area of storage management services, enhanced client support, enhanced and integrated utilities, and better online documentation.
Test questions can have a single correct answer or multiple correct answers. When a single answer is desired, this is indicated by a l notation that precedes the possible answers. Some questions require you to select more than one answer; these are indicated by the n preceding each answer. Taking practice quizzes will not only test your knowledge but will also give you confidence when you take your exam.
A. runs workstation software and server software
B. runs the same software as a NetWare workstation
C. runs networking software that allows it to share its resources and services with other users on the network
D. runs networking software that allows it to use resources and services on other network servers and workstations
A. Distributed
B. Shared
C. Centralized
D. Global
A. redirector
B. shell
C. client
D. service requester
A. file system security only
B. multiple levels of security
C. general database services
D. logical organization of network resources
E. global data access services
A. eliminates the need to create user objects
B. eliminates the need to create user and group objects
C. eliminates redundant tasks such as adding a user account to multiple servers on the network
D. provides access to network resources
E. provides a general database service
A. access to a general database
B. logical organization of network resources
C. no need to create user objects
D. group login to the network
A. NetWare DOS Requester
B. DOS
C. NetWare shell
D. OS/2
A. NETX.COM
B. NetWare shell
C. A Network Interface Card (NIC) Driver
D. VLM.COM
A. network devices that use same protocols to share the same physical network
B. network devices that use different protocols to coexist and share the same physical network
C. network devices that use different protocols to interoperate
D. workstations using different protocols to communicate with a NetWare server using IPX protocol
A. a Network Interface Card (NIC) Driver
B. VLM.COM
C. DOS
D. communication protocols
E. NetWare DOS Requester
F. OS/2
G. NetWare shell
A. share the same network adapter and cabling system
B. coexist as long as they are running at different workstations
C. coexist at a workstation
D. use the same NetWare server
A. a network adapter driver to be written just once for different types of communication protocols
B. multiple protocols to share the same network adapter and cabling system
C. multiple protocols to coexist as long as they are running at different workstations
D. multiple protocols to coexist at a workstation
A. Link Support Layer (LSL)
B. NE2000.COM
C. Multiple Link Interface Driver (MLID)
D. IPX.COM
A. must be loaded after the ODI driver
B. acts as a switchboard to route packets to the correct protocol and correct ODI driver
C. must be loaded before the ODI driver
D. provides communications between the workstation software and network services
E. provides a network redirector function
A. IPXODI.COM
B. VLM.EXE
C. IPX.COM
D. LSL.COM
E. NETX.EXE
F. NE2000.COM
A. used to refer to network adapter drivers that support the ODI specification
B. a set of special network adapters that support the ODI specification
C. used to communicate between the network adapter and the Link Support Layer
D. a protocol that stands for Multiple Layer Internetworking Device
E. a protocol module that implements the SPX/IPX protocols
A. CONFIG.SYS
B. AUTOEXEC.BAT
C. NET.CFG
D. NET.DAT
E. STARTNET.BAT
A. LSL.SYS
B. LSL.COM
C. LINK.COM
D. LINKS.COM
E. LINKS.SYS
A. ETHERNET_SNAP
B. ETHERNET_II
C. ETHERNET_802.3
D. ETHERNET_802.2
A. DEVICE=HIMEM.SYS
B. DEVICE=SMARTDRV.SYS
C. LASTDRIVE=Z
D. LASTDRIVE=E
A. MLID driver, LSL.COM, IPXODI.COM, VLM.EXE
B. LSL.COM, IPXODI.COM, MLID driver, VLM.EXE
C. LSL.COM, MLID driver, IPXODI.COM, VLM.EXE
D. MLID driver, IPXODI.COM, LSL.COM, VLM.EXE
A. CALL C:\NWCLIENT\STARTNET.BAT
B. STARTNET.BAT
C. NETSTART.BAT
D. CALL C:\NWCLIENT\NETSTART.BAT
A. must have the LASTDRIVE=E statement set in the NET.CFG file
B. can coexist with the older NetWare shell
C. logically resides between workstation software and network adapter and enables communications between them
D. logically resides between workstation software and network services and enables communications between them
A. the NetWare shell
B. DOS
C. DOS and then by the NetWare shell
D. the DOS Requester
A. IPX request for services
B. NCP request for services
C. SPX request for services
D. IP request for services
A. DLLs
B. NLMs
C. VLMs
D. the NetWare shell
A. and activates the NetWare DOS Requester
B. the IPXODI.COM, if it is not already loaded
C. the LSL.COM
D. the VLMs and the ODI interface modules
A. device driver, VLM.EXE
B. TSR, VLM.EXE
C. device driver, VLMs
D. TSR, VLMs
A. managing VLMs and NLMs
B. loading the NetWare shell and associated protocol modules
C. managing device drivers loaded from the CONFIG.SYS file
D. controlling VLMs and access to memory at the workstation
E. managing data flow and communications between VLMs
A. only needed components are loaded, which reduces workstation memory overhead
B. coexistence of NetWare shell and the NetWare DOS Requester
C. because the requester consists of smaller number of components, each of these components has a better chance of being loaded in upper memory than if it was one large module
D. it opens up the workstation architecture for development by third parties who can write additional VLM components
E. the ability to load all dependent protocol modules on demand priority
A. VLM ALTER.CFG
B. VLM /C=C:\CONFIG\ALTER.CFG
C. VLM /D=C:\CONFIG\ALTER.CFG
D. VLM
A. VLM /ME
B. VLM /M=EXP
C. VLM /MC
D. VLM /M=E
E. VLM /M=X
F. VLM /M=C
A. it maps the next drive specified after the LASTDRIVE statement in CONFIG.SYS as a network drive
B. it maps the drive specified in the NETWORK DRIVE statement in NET.CFG as a network drive
C. it maps the drive specified in the FIRST NETWORK DRIVE statement in NET.CFG as a network drive
D. it maps the drive specified in the FIRST NETWORK DRIVE statement in the NetWare DOS Requester section of the NET.CFG as a network drive
A. Frame ETHERNET_802.2
B. LASTDRIVE=Z
C. NetWare DOS Requester
D. FIRST NETWORK DRIVE=Z
E. FIRST NETWORK DRIVE=F
© Copyright, Macmillan Computer Publishing. All rights reserved.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}