The goal of network client configuration is to enable the client to use the network with the optimal balance of high performance and low memory use. When you factor in your time constraints, finding that balance can be something of an art form.
This chapter looks at network software configuration for clients. It examines the software components and how to install them, and it covers network and memory configuration issues. It gives you the information you need to get a reasonably well-configured client up and running in a reasonably short time and to fine-tune that client to meet your particular requirements.
This part of the chapter deals with the nuts and bolts of client configuration. It describes how to install and configure the various software components, and it takes a detailed look at the numerous configuration parameters.
The broad idea behind client configuration is to allow your client workstation to transmit and receive packets of a particular type (or types) on your network. Before you begin, you need to know which Ethernet frame type the server uses and which protocol or protocols your client is going to use.
There are two major elements to network client software. First, there is the network driver, the software that controls the network adapter. Then there is either a shell or redirector to translate all the network traffic into something meaningful to the OS.
The form taken by both of these components has changed considerably over the last few years. Broadly speaking, DOS workstations have seen three types of configurations:
The next few sections look at the various components.
The original NetWare network drivers were monolithic, dedicated IPX drivers. A single executable file contained all the software needed to control the network adapter, along with the hardware configuration information for the adapter.
Adapter manufacturers distributed their NetWare drivers as an object file, which then was linked to NetWare code to produce an executable file with the adapter configuration embedded in it. If one of the adapter parameters was changed, the driver had to be rebuilt. These drivers supported IPX only-no other protocol could be used while they were loaded and in control of the network adapter.
Such drivers are obsolete and therefore are discussed no further in this chapter.
Dedicated IPX drivers are obsolete! If your workstation currently uses such a driver, refer to "Upgrading Client Software" later in this chapter, for more information.
How do you tell if the network driver on a workstation is a dedicated IPX driver or not? Dedicated IPX drivers generally are named IPX.COM; however, the name may have been changed to indicate the type of adapter the driver supports. You may not be able to tell from the time stamp on the file, either. Although Novell has not certified monolithic drivers for network adapters since 1990, the COM file might have been linked since then. The best way to tell if a network driver is a dedicated IPX driver or not is by trying to load it without the Link Support Layer (see the following section)-if it complains about the LSL not being loaded, then it is an ODI driver rather than an IPX driver.
Novell developed the Open Datalink Interface (ODI) specification with Apple in 1989. A network driver that complies with this specification is known as a Multiple Link Interface Driver (MLID).
The strength of the ODI concept lies in its modularization of network functions. There are at least three components in the adapter driver software end of an ODI client:
These work together according to the instructions in the configuration file NET.CFG to provide network connectivity to the OS. The following sections look at each component in turn.
The MLID handles all communications between the physical network adapter and the other network components. Each adapter model needs its own MLID; these are written and distributed by the adapter manufacturers.
The MLID is the only software component that deals directly with the adapter. If you replace an adapter with a different model, just swap in the MLID for the new adapter and update the NET.CFG file.
The Link Support Layer (LSL) communicates between the MLID and the various protocol drivers (such as IPXODI) as described later.
The LSL may seem like an extraneous layer. Why not have the protocol drivers talk directly to the MLID? The answer lies in the benefits of modularizing the network functions. Consider the complexity of an ODI workstation. It may have several network adapters, each using multiple protocols. Network traffic must be routed between each adapter and the protocol-specific software that uses it. It would be quite difficult for a number of MLIDs in memory to coordinate their traffic-passing with each other. Even a single MLID for a single adapter would have difficulty keeping the various protocols separate, passing each type of traffic on to the correct driver.
The LSL lies between the MLID and the protocol drivers in logical-or
even purely chronological-terms. It passes data from the MLID to the protocol
drivers, and vice versa. It must, however, be loaded before the MLID. This
is because the MLID needs to have the LSL to communicate with as soon as
the MLID loads and also because there might be many MLIDs but only one
LSL. It is easier to get each MLID to register with the LSL as
it loads than to try to get the LSL to figure out which MLIDs are present
when the LSL loads.
MLID and LSL can look after the delivery of data from the adapter to the protocol drivers and vice versa. The purpose of the drivers is to interpret incoming data and to package outgoing data, according to the protocol that they support.
IPXODI, for example, looks after incoming IPX packets, unpacks them
and passes them on to the shell or redirector. Likewise, it accepts data
from the shell or redirector for packaging as IPX packets and then passes
them on through the LSL to the MLID for
processing by the adapter.
This is where the versatility of the ODI scheme is most apparent. If your workstation needs only IPX support, just load IPXODI. If you want to add TCP/IP support, load TCPIP.EXE or some similar driver. Provided you keep the NET.CFG file in order, the workstation then handles both protocols.
The NetWare shell, NETX.EXE, adds network functionality to the workstation environment by intercepting calls made to DOS and handling some of them itself.
Early versions of the NetWare shell were DOS version-specific. NET3.COM worked with DOS 3, NET4.COM worked with DOS 4, and so on. More recent versions work with any DOS version and are named NETX.EXE. Notice that it has become an EXE file rather than a COM file-if you have NETX.COM, it's obsolete.
NETX is loaded into the workstation's memory when the workstation makes its initial connection to a file server. From then on, it watches a number of DOS interrupts. If an interrupt request can be handled by the OS, NETX simply passes it on to DOS.
If an interrupt call was made that requires action by NetWare rather than by the OS-for example, a reference to a network drive-NETX handles the interrupt itself. It puts together an IPX request and passes it on to the network via the network adapter and its associated software. Figure 11.1 illustrates the relationship between DOS, NETX, and the other network components.
Figure 11.1 NETX intercepts DOS calls and redirects them to network resources.
The NetWare requester, VLM.EXE, also adds network functionality to the workstation environment; however, it does so quite differently than the NetWare shell does.
The requester incorporates a redirector that relies on DOS's redirection capabilities. If DOS receives an interrupt request relating to a network service, such as access to a network drive, it passes the request on to the requester. The redirector then handles the request in much the same way as the shell would-it makes an IPX request and transmits it to the network. Figure 11.2 illustrates the relationship between DOS, VLM, and the other network components.
Figure 11.2 The VML requester takes advantage of DOS's ability to redirect interrupt requests.
The requester has a modular architecture. Virtual Loadable Modules (VLMs) are loaded by the VLM.EXE as required. Modules that are not needed do not need to be loaded. Individual modules may be replaced or reconfigured without affecting other modules. The requester uses advanced memory management techniques to make optimal use of client memory.
Table 11.1 lists the available VLMs. Notice that some VLMs are required and others are optional. If you are unsure whether a VLM is required, you can load it anyway-it won't clash with another VLM. Be aware, though, that there is a memory cost for each VLM loaded. A better approach is to omit the VLM and see if you can get by without it. If you get error messages, you can always include the required VLM later.Table 11.1 Virtual Loadable Modules
File |
Manages |
Required |
|---|---|---|
AUTO.VLM |
Auto reconnection and |
No |
auto retry |
||
BIND.VLM |
NetWare protocol |
Bindery mode only |
(Bindery) |
||
CONN.VLM |
Connection table |
Yes |
FIO.NLM |
File input/output |
Yes |
GENERAL.VLM |
Support functions for |
Yes |
NETX and REDIR |
||
IPXNCP.VLM |
IPX communications |
Yes |
MIB2IF.VLM |
MIB-II interface |
No |
MIB2PROT.VLM |
MIB-II TCP/IP support |
No |
NDS.VLM |
NetWare protocol (NDS) |
NDS mode only |
NETX.VLM |
NetWare shell emulation |
No |
NMR.VLM |
NetWare management |
No |
responder |
||
NWP.VLM |
Multiplexor for |
Yes |
NetWare protocols |
||
PNW.VLM |
NetWare protocol |
PNW mode only |
(Personal NetWare) |
||
PRINT.VLM |
Printer redirection |
No |
REDIR.VLM |
DOS redirector |
Yes |
RSA.VLM |
Encryption for |
No |
Directory Services |
||
SECURITY.VLM |
NetWare security |
No |
TRAN.VLM |
Multiplexor for |
Yes |
transport protocols |
||
WSASN1.VLM |
SNMP ASN translation |
No |
WSREG.VLM |
MIB network management |
No |
WSSNMP.VLM |
SNMP network management |
No |
WSTRAP.VLM |
SNMP traps |
No |
There are a number of differences between the shell and the requester, in terms of both architecture and the user's point-of-view:
The next few sections explore these differences.
The requester consists of a number of VLMs and the VLM manager, VLM.EXE. VLM.EXE takes care of loading the VLMs into the workstation's memory, as well as managing memory allocation from various sources to the VLMs.
This modular approach differs from the monolithic NETX.EXE, which consists of a single file with a single memory allocation. NETX takes up one large chunk of memory rather than several small chunks. NETX also encapsulates all network functionality in a single file. The VLMs, in contrast, modularize network functionality so that unneeded components need not be loaded.
VLM.EXE looks after memory allocation for the VLMs. It is capable of using conventional, extended (XMS), and expanded (EMS) memory. Unless instructed otherwise, it loads individual VLMs into memory in the following order of preference:
Therefore, the first few VLMs can be loaded into XMS while others are loaded into EMS or conventional memory. Using XMS rather than conventional memory has a performance cost, however-XMS is slower to access than conventional memory.
When the shell is in use, it gets first call on requests. It decides which requests are network-related and which are not; any non-network requests are passed to DOS. When the requester is in use, though, DOS gets first call. DOS decides which requests are network-related and which are not; network requests are passed to the VLMs.
This architectural difference has several implications, as explained in the following sections.
The NetWare shell creates drive mappings using only drive letters that are not in use by DOS. If DOS uses drives A through E (the default), then the first network drive is drive F, and drives F through Z are available for mapping by the shell. If a DOS request comes through for drive M, it is handled by the shell. If a request comes along for drive C, the shell passes it along for DOS to deal with.
The requester doesn't work that way-remember that it only has to handle requests that DOS decides are network requests. If DOS is using drives A through E, and a request comes along that refers to drive M, DOS returns an Invalid drive error, and the requester never sees the request.
It is necessary when using the requester to tell DOS to use more drive letters than the default five (A-E). It usually is best to make all drive letters available by setting the last DOS drive to Z. This is done by using the command
LASTDRIVE=Z
in the workstation's CONFIG.SYS file.
Once this has been done, requests involving network drives are handled differently. If a DOS request comes through for drive M, DOS recognizes the drive letter as valid but also recognizes that VLM.EXE has taken over the operation of drive M. It therefore passes the request on to the requester for handling. Requests for local drives such as drive C are handled in the normal way, without the involvement of the requester: DOS recognizes the drive, knows that the drive is DOS's responsibility, and therefore handles the request itself.
The shell and requester both map the first network drive to the server's logon area when the initial connection is established.
Using NETX, the first network drive is the next drive after the local drives or DOS drives. Assuming that the workstation uses the DOS default of five available drives (A-E), the first network drive is drive F. This is true even if some of the DOS drive letters are unused. If there is no hard disk, for example, and only drives A and B are in use, the first network drive still is drive F.
As explained in the preceding section, DOS and the requester share a range of drive letters. DOS examines each request and either deals with the request itself (if for a local drive) or passes the request on to the requester (if for a network drive). The mechanism used by NETX to decide on the first network drive-the first one after the DOS range-therefore does not work. Instead, VLM uses the first available DOS drive letter for the first network drive. If a workstation has no hard disk, for example, and uses only drives A and B, the first network drive is drive C; if the workstation has a hard disk drive (C) and a CD-ROM drive (D), the first network drive is drive E.
You can force VLM to use a particular letter as its first network drive by using the First Network Drive parameter in NET.CFG. See the "NET.CFG Parameters" section, later in this chapter, for details.
The DOS prompt looks different when you switch to the first network drive, depending on whether you use NETX or VLM. Suppose that the first network drive in each case is drive F.
Under NETX, the mapping is not a fake root-the DOS prompt reads F:\LOGIN>. You cannot switch to the root directory, F:\, until you log on. That does not matter to NETX-it happily intercepts all requests that refer to drive F and makes sure that you do not get to F:\.
This is not true of DOS because DOS cannot maintain a subdirectory when the parent directory is inaccessible. As soon as VLM attaches to the file server, it creates a root mapping to the logon area; therefore, the DOS prompt reads F:\>.
Drive mappings in Windows DOS sessions using NETX are private by default. Under VLM, such mappings are global. This means that if you have multiple DOS sessions running, and you change a drive mapping in one session, the drive is also remapped in the other sessions.
NETX regards network files as its own. It allocates handles for these files when it loads, either using the default value of 40 or a different number if there is a File Handles= entry in NET.CFG. Local files are DOS's business and have nothing to do with NETX, so DOS maintains file handles for local files. The number of file handles used by DOS can be set in CONFIG.SYS using the FILES= statement.
Using VLMs, all file handles are managed by DOS. The total number of network and local file handles is set in the CONFIG.SYS file using the FILES= statement. You might need a larger FILES= setting in CONFIG.SYS when using VLMs.
The installation procedure for the NetWare clients for DOS and Windows has been greatly simplified over the years. The original monolithic adapter driver had to be generated from its component parts into an executable file (IPX.COM) with the adapter's hardware settings hard-coded into the driver. To change a setting, the entire driver had to be recompiled. Once this was done, however, the simple loading of two TSRs from the workstation's AUTOEXEC.BAT was the only remaining procedure.
The advent of the ODI architecture eliminated the need for driver generation and eased the process of configuring the adapter's hardware settings. It also simplified the procedure for using multiple network protocols on a workstation. However, as a result, the number of executables required increased from two to four.
The VLM client plus the adoption of Microsoft Windows as the standard business workstation environment increased the complexity of the NetWare client beyond the point at which it could be conveniently installed manually. Finally, an installation program was created for the VLM client that automates the procedure. If you are installing network support to a workstation for the first time, the use of the automated installation program is highly recommended.
The NetWare VLM client installation files ship with the NetWare 4.x operating system. It is installed by default to the \PUBLIC\CLIENT\ DOSWIN directory during the normal NetWare server installation process. The kit is also available for download from Novell's NetWire service on CompuServe.
The NetWare VLM Client Installation Kit is available from CompuServe (GO NWCLIENT) as six files called VLMKT1.EXE through VLMKT6.EXE. VLMKT6, however, contains only support for TCP/IP. If you will not be running Novell's TCP/IP, you do not need to download this file. Note that the full VLM kit contains all of the modules needed to support NetWare in all its available languages. The client upgrade archives mentioned elsewhere in this chapter, such as WINDR3.EXE, support U.S. English only.
You don't need a complete client installation to establish basic network connectivity. In the case of most corporate networks, an administrator uses a boot disk containing the basic files needed: LSL.COM, and MLID, IPXODI.COM, and NETX.EXE to connect to the network, from which she runs the full client installation.
If you have downloaded the Client Installation Kit from an online service, copy all the self-extracting files to a single empty directory and execute each one in turn. After you agree to the Novell terms and conditions, the files are decompressed and a directory structure is created. Certain files, such as NWUNPACK.EXE and LICENSE.TXT, exist in all of the archives. You can safely overwrite these files, as they are not required for the client installation.
Once you have extracted the archives, run the INSTALL.EXE program from the directory you have created. The VLM client installation program then performs the following tasks:
After you have completed the installation process, you may want to make additional adjustments to the NET.CFG file using the settings explained in "NET.CFG Parameters," later in this chapter. You should, however, be able to reboot your system and connect to the network.
There is no dedicated installation program for the NETX client. If you have reason to perform an installation of the NETX client on a new computer with no networking support, you should still utilize the VLM Installation Kit to install the client, and then substitute NETX.EXE (or XMSNETX.EXE or EMSNETX.EXE) for VLM.EXE in the STARTNET.BAT file. This way, you have a complete set of client files that have been tested and are known to work together.
If you are familiar with the structure of the NET.CFG file and you will not be running Windows on the computer, then you may find it simpler just to copy LSL.COM, and MLID, IPXODI.COM and NETX.EXE to a workstation drive and load them from the AUTOEXEC.BAT file-once you have created a NET.CFG containing the appropriate hardware settings. Most NetWare client workstations today are used to run Windows, however, and while you can install the client's Windows support manually (see "Manually Upgrading Windows Network Components," later in this chapter), it is far simpler to use the installation program.
Every network client machine requires a software upgrade sooner or later. The upgrade may be prompted by a hardware or operating system change, the need to replace buggy or inefficient software, or the desire to take advantage of the enhanced functionality of newer software.
This section describes why, when, and how to upgrade the client network software components. It tells you which files you should have and what you are missing in each case by not upgrading. It also explains how to replace existing software as smoothly as possible. It points out the changes you can expect and shows how to avoid losing functionality-including the ability to use the network-by taking appropriate precautionary steps.
This chapter is focused on the upgrade procedures per se rather than on the particular software components. It may tell you, for example, that you should upgrade from IPX.COM to an ODI driver without giving a full explanation of what an ODI driver is.
You want client upgrades to be successful and worth the effort. An upgrade that adds nothing to the client is a waste of time; if the client loses functionality as a result of your efforts, you will have to restore it to its previous state. The following precautionary steps can help you to ensure a successful upgrade and to backtrack gracefully in the event of a disaster.
Few experiences in network configuration can match the feeling you get when an upgrade kills the client so that it can no longer connect to the network. This is especially true if you skipped the step of backing up all network related files before carrying out the upgrade.
It is generally advisable to have a full backup of all hard disks in the system before carrying out any software upgrades-network or otherwise. Before you dismiss this as excessively cautious, consider the implications for yourself and for the users of the workstation if data is lost on the hard disk. If you are about to upgrade a workstation that is maintained by someone else, ask him first if the backups for the machine are in a satisfactory state. If not, you should warn him that there is a risk of data loss during the upgrade.
Make a backup copy of all network files on floppy disk or copy them to another directory or extension (such as *.OLD) before carrying out an upgrade that might replace any of them. Use the following checklist as a guideline:
Remember to check in subdirectories for these files. There may be older versions of the files in one directory and more recent versions in another. This is bad practice but it does happen, and it can mean that you accidentally back up the wrong files. Check AUTOEXEC.BAT to see where the files are loaded from.
Look for different versions of the Windows network files in both the \WINDOWS and \WINDOWS\SYSTEM subdirectories. If you find any, make backups of both for simplicity. Copy them to separate subdirectories on the backup floppy. You can experiment with deleting older versions and moving newer versions to the correct location after the successful completion of the upgrade.
Make sure you have a bootable floppy disk before starting the upgrade process. Check that it works on the specific client machine that you are configuring and that the hard disk is accessible after booting from it.
Ideally, use a floppy boot disk formatted using the same DOS version as the one installed on the PC. Using a floppy boot disk with the same DOS version means you can use the external DOS commands stored in the PC's DOS directory after booting from the floppy.
Copy your favorite utilities to the floppy boot disk so they will be ready when you need them. Include a text editor for working on the PC's configuration files.
There may be old versions of the network files lying around in directories other than the one from which the current files are loaded. Search for any such files and remove them from the hard disk before starting the upgrade. This helps to avoid confusion at a later stage, when it might not be clear which copy of a particular program should be loaded. It is best to keep copies of these files on a special backup floppy disk for reference purposes and as a safety precaution.
You may need to establish the current version number and revision level of a particular file before you can decide whether to replace it with another. There are a number of ways to do this.
A simple comparison of file dates is often sufficient. If one copy of LSL.COM is from 1992 and another from 1994, install the 1994 version. Sometimes the date stamp is misleading though; for example, it may be the date on which the file was downloaded from an online service.
In many cases, running the program with the /? command line option gives quite detailed version information. Compare the first line in the /? output from two copies of LSL.COM:
The version numbers tell you that the second file is the more recent. The date stamp in parentheses at the end of the line tells you how much more recent: the first was released on September 10, 1993, and the second on October 11, 1994.
In some cases, you can't trust even this information. MLIDs are particularly
prone to mislabeling, as hardware manufacturers can be sloppy about software
version numbering. For example, two early versions of ODIDEPCA.COM reported
the same version
number:
Yet the second is eight months more recent than the first and is considerably more reliable.
In summary, compare file date stamps and the version numbers reported by the programs themselves, but don't rely completely on this information. The only way you can be certain you have the most recent version of a file is to contact the supplier, as explained in the next section.
The most recent versions of the NetWare files-LSL.COM, IPXODI.COM, NETX.EXE, VLM.EXE, and the Windows files-can be found in Novell's NETWIRE forum on CompuServe and in various Internet mirrors. If you don't have access to the Internet or to CompuServe, your NetWare dealer should be able to provide these files to you.
All the NetWare client update archives can be downloaded from the NWOSFILES forum on CompuServe.
Novell packages the files into a number of self-extracting archives,
each of which contains a set of related files. The latest VLM files at
the time of writing, for example, are distributed in a file called VLMUP4.EXE.
Unpack the archive into a new, empty directory to avoid mixing up its contents
with any older files. Use the following commands to
do so:
The contents are unpacked from the archive file into the current directory. Any subdirectories contained in the archive file are automatically re-created in this directory.
The easiest place to find an MLID for your network adapter is on the adapter configuration disk supplied with the adapter. The place to find the most recent one is usually on the adapter manufacturer's World Wide Web or FTP server or in their CompuServe forum.
The following pages look at the various client network software components in turn. Topics covered include reasons for upgrading, upgrade instructions, and the benefits of particular upgrades.
IPX.COM and NETX.COM should simply not be used anymore.
Novell stopped certifying dedicated IPX drivers years ago. If any of your workstations still use one, it's time to get rid of it.
Replace IPX.COM (or whatever the dedicated IPX driver is called on your workstation) with a recent version of the Multiple Link Interface Driver (MLID) for your network adapter. Refer to the following "ODI Files" section for details.
Upgrading from a dedicated IPX driver to an MLID provides the client with a more robust and flexible interface. Above all, it gives the client the ability to run multiple network protocols simultaneously.
The NetWare shell was originally DOS version specific, with NET3.COM written for DOS 3 and NET4.COM written for DOS 4. These were replaced with a single shell that worked on all DOS versions: NETX.COM. This was replaced in turn by NETX.EXE.
If NET3.COM, NET4.COM, or NETX.COM is in use on the workstation, replace it with the most recent version of NETX.EXE (see the "NETX.EXE" section later in this chapter). Alternatively, migrate to the NetWare DOS requester, as discussed in the "Migrating from NETX to VLM" section later in this chapter.
The modular architecture of ODI means there are at least three network programs to upgrade on a NetWare client. These are the Link Support Layer driver (LSL), the IPX driver (IPXODI), and the MLID for the workstation's network adapter.
The functionality of LSL is clearly defined in the ODI specification. Newer versions offer bug fixes or efficiency improvement over older versions without any change in core functionality. In other words, upgrading LSL.COM won't break anything but it may fix a problem or avoid a potential problem, so always use the most recent version!
At time of writing, the most recent LSL.COM available on NetWire is v2.14, released on April 17, 1995. Check the current revision of your copy of LSL.COM by using LSL's /? switch:
Upgrading from an old version is a snap-just replace the old version with the new one. Installing ODI drivers from scratch-for example, when upgrading from IPX.COM to ODI-is more complex.
Like LSL, IPXODI has a clearly defined role in the ODI scheme and is a stable entity as a result. It cannot change dramatically between releases; to do so would disrupt a huge number of client machines around the world. New releases generally offer bug fixes.
Check the version of your current copy of IPXODI.COM using IPXODI's /? switch:
C:\> IPXODI /? NetWare IPX/SPX Protocol with Mobile Support v3.02 (950808) (C) Copyright 1990-1995 Novell, Inc. All Rights Reserved.
The current version of IPXODI.COM at time of writing is v3.02, released on August 8, 1995.
Just as for LSL.COM, you can replace an old version of IPXODI.COM with a newer version by simply replacing it. Always use the most recent version you can find-as a minimum, you will avoid potential problems that may be inherent in the older version.
LSL.COM and IPXODI.COM are universal in application, in the sense that they are designed to run on any PC with any network adapter. They are tested exhaustively before being released, and the introduction of new problems in an upgrade of either file is very unlikely.
This is not the case with the ODI driver or MLID for a given network adapter. These programs are written by the adapter manufacturer, working to the ODI specification. MLIDs are occasionally released with serious bugs that have escaped the manufacturer's testing procedures. This is particularly true of initial releases of drivers; if you are having strange network problems while using version 1.00 of the ODI driver for a particular adapter, an upgrade is a good idea.
You can generally establish the current revision number and release date of an MLID using the /? command-line option. Here's an example from the 3Com Etherlink II MLID:
3Com 3C503 EtherLink II MLID v1.30 (930203) (C) Copyright 1992 3Com Corporation. All Rights Reserved. (C) Copyright 1991 Novell, Inc. All Rights Reserved.
Upgrading an MLID is the first step to take if you are experiencing unusual, client-specific network problems that you cannot reliably attribute to any other source. Keep a copy of the old version in case the new one is faulty.
A little more care is necessary when upgrading the MLID than when upgrading LSL. This is because the MLID works in close cooperation with the workstation's hardware, particularly the network adapter and system RAM. It is not a simple "plug-in" component like LSL. In particular, default settings may change from one version of an MLID to the next; values that you did not need to specify in NET.CFG may need to be explicitly stated when using the new version.
The following procedure explains how to upgrade a given MLID. It is assumed that you have located a new version of the MLID and verified that it is designed for use with your particular adapter model. It is also assumed that you have taken all the precautions listed in the "Backups" section earlier in this chapter.
On those rare occasions when an MLID upgrade results in a deterioration in client performance, be ready to switch back to the previous MLID while you source a newer driver from the adapter manufacturer.
