Novell is now a part of Micro Focus

Disconnecting NetWare Clients that Have Automatic Reconnection Enabled

Articles and Tips: article

Senior Research Engineer
Novell Developer Information

01 Feb 1997

Ever tried to clear the connection of a workstation that has auto-reconnect enabled? It keeps coming back...unless you know the trick outlined in this AppNote.


One of the features implemented in Novell's latest NetWare DOS Requester and NetWare Client 32 client software is automatic reconnection, or auto-reconnect. When auto-reconnect is enabled, the client software is able to automatically re­establish a user's connection when communication with a NetWare server is temporarily lost. Once the server resumes operation, the client is reinstated into the server's connection table without the user having to log back in. Normally, this is a good thing, as it allows the user to resume working with minimal interruption.

However, there are times when a network administrator needs to perform server maintenance operations, such as full backups or software upgrades, that require all users to be off the server. It seems there are always a few users who forget to log out at the end of the day, leaving their workstations fully connected. In such a situation, you can always go into the MONITOR utility's Connection Information option and clear users' connections from there. But workstations running the NetWare DOS Requester or Client 32 with auto-reconnect enabled keep reattaching and coming back into the connection table.

This AppNote describes how to disconnect users from a NetWare server long enough to perform necessary maintenance operations. It first explains the types of connections that are possible on NetWare 3.x and NetWare 4.x/ IntranetWare servers, and gives some background information on the automatic reconnection capabilities of the NetWare DOS Requester and NetWare Client 32.

Types of NetWare Connections

Let's look first at the types of connections you can see through the Connection Information option of the server's MONITOR utility. We'll discuss connection types for both NetWare 3.x and IntranetWare/NetWare 4.x.

NetWare 3.x

On NetWare 3.x servers, you can see two types of connections in MONITOR's Connection Information option: Not-Logged-In and licensed.

Not-Logged-In Connection. The Not-Logged-In connection type is the initial connection a workstation makes when it is trying to connect to a server. As the NetWare client software loads, the workstation sends an initial "Get Nearest Server" broadcast request to connect to any server on the network. The first server to reply to this broadcast with a "Give Nearest Server" information establishes a temporary connection with the workstation. At this point, the connection appears in the server's connection table as Not-Logged-In.

If the user has specified a Preferred Server either in the NET.CFG file or at the command line and the initial server is not the preferred server, the initial server looks in its Routing Information Table to find the preferred server. It then routes the workstation's request to that server, which responds to the workstation with the nearest route information for direct communication. The Not-Logged-In connection type now appears in the preferred server's connection table.

Licensed Connection. After the user types in the correct username/ password combination and begins the login process, the user is authenticated to that server. You see the user's name associated with the connection number in the server's connection table, which now takes up a licensed connection.

NetWare 4.x/IntranetWare

In NetWare 4 and IntranetWare, there are three types of connections: Not-Logged-In, Authenticated, and Authenticated/Licensed.

Not-Logged-In Connection. A Not-Logged-In connection is the same as what you see in NetWare 3.x: the initial attachment of the workstation before authentication or licensing occurs. It is displayed in MONITOR as "NOT-LOGGED-IN" in the Active Connections window. This could also be a user who has logged out, leaving a Not-Logged-In connection to the server on which his or her default drive was located.

Authenticated Connection. The Authenticated connection is an unlicenced connection that can access Novell Directory Services (NDS) but can't, in its current state, access the server's file or print services. These entries appear in MONITOR's Active Connections windows with an asterisk (*) by their object name.

This type of connection most often occurs when users are browsing the NDS tree to view objects located in an NDS replica held on another server. They can also be from other NetWare servers carrying out NDS synchronization or time synchronization activities. These types of connections do not count against the number of allowable license connections for the server.

Authenticated/Licensed Connection. In NetWare 4.x, the authenticated state occurs when the user enters the correct username and password. From this information, NDS establishes the user's identity and authenticates the user via the security methods found in its encryption algorithms. However, a user's connection doesn't become authenticated and licensed until the user requests access to the server's file and print services. Typically, such requests are initially performed through the container, profile, or user login script. Once the user is authenticated during the initial login process, background authentication establishes connections to any other servers that are designated in the user's login script. An authenticated/licensed connection uses up one of the NetWare server's licensed connections.

Figure 1 is a sample MONITOR screen showing the three different types of connections described above.

Figure 1: Sample MONITOR screen showing the three types of connections possible on NetWare 4.x and IntranetWare servers.

NetWare Client Auto-Reconnection Capabilities

The NetWare DOS Requester (VLMs), NetWare Client 32 for DOS/Windows 3.x, and NetWare Client 32 for Windows 95 all have automatic reconnection capabilities. With the DOS Requester, you can set up a workstation to re­establish server connections, drive mappings, and printer captures. Client 32 takes auto-reconnection to the next level by keeping track of open files and file locks, thus enabling a complete restoration of the user environment after a network failure.

Setting Up Auto-Reconnect in the NetWare DOS Requester

To use the DOS Requester's automatic­reconnection capabilities for NetWare and IntranetWare, you must have DOS Requester version 1.20 or higher, as well as NETWARE.DRV version 3.03 or higher. This DOS Requester version and driver come with the NetWare 4/IntranetWare operating systems. If you have an earlier version, download the WINDRx.EXE file (where x is "2" or higher) from the NOVLIB section of CompuServe or from Novell's support page on the World Wide Web

To set up reconnection capabilities for the DOS Requester, place the following lines in the NET.CFG file, indented under the NetWare DOS Requester heading:

VLM = AUTO.VLM     (not loaded automatically) VLM = RSA.VLM   (not loaded automatically) Auto Reconnection=ON   (ON is the default) Auto Retry=nn   (must be set to a number from 1 to 3640)

The value of the Auto Retry parameter specifies how many seconds the client software will wait after an unsuccessful attempt to reconnect before trying again.

Once these settings are in place, reboot the workstation to initiate the auto-reconnect capabilities. You can test whether auto-reconnect is working by logging in as a user at the workstation and mapping some network drives. Then go to the MONITOR utility at the server, select Connection Information, highlight the user in the Active Connections window, and press <Del< to clear the user's connection. Back at the workstation, type the MAP command to request a server resource. At the server, you should see the user's connection reappear in the Active Connections window­ first as a Not­Logged­In connection, then re­established as a licensed connection with the username displayed.

If the user is in an application when the connection is cleared, the workstation will regain its connection to the server, its drive mappings, and printer captures. However, with the DOS Requester no active files are restored, so any unsaved data in the application will be lost­ depending on how the application handles network connection losses.

Setting Up Auto-Reconnect with Client 32

With both Client 32 for DOS/Windows 3.x and Client 32 for Windows 95, auto-reconnect is enabled by default. In addition, Client 32 supports file caching on the client side, which allows files to be cached as they are read from the server and as they are written to the server. Thus there are three parameter settings you should be aware of when dealing with automatic reconnection: Auto Reconnect, File Cache Level, and Max Cache Size.

For Client 32 for DOS/Windows, these settings are placed in the NET.CFG file, indented under the NetWare DOS Requester heading: Auto Reconnect = 3 File Cache Level = 3 Max Cache Size = nn    (0 to 24576 KB)

For Client 32 for Windows 95, these settings are found in the Network window. To access this window quickly, hold down the Alt key and double-click on the Network Neighborhood icon. Under the Configuration tab, highlight the Novell NetWare Client 32 entry and click on the Properties button. Then select the Advanced Settings tab. Any changes you maketo these settings are placed in the Windows 95 registry.

Let's look at each of these three settings in more detail.

Auto Reconnect Level. The Auto Reconnect Level parameter has five possible settings:





Restoresserverconnections, drive mappings, and printercaptures(same level of support as in theNetWare DOSRequester)


Restorestheabove elements, plus read-only files(notfiles that have been written to)


(Defaultsetting) Restores the above elements, plusall filesand file locks; performs a Abest­guess@rewriteof data after reconnection


Restorestheabove elements, plus performs additionalfilewrite data recovery guarantee to ensuredataintegrity on reconnection

File Cache Level. The File Cache Level parameter can be set from 0 to 3, with the different settings as follows (the larger the number value, the better the performance):



Nofilecaching (0 turns caching OFF)


Read­ahead,write­behindcache (uses 14KB cacheblock per open file)


Cacheallopen files as long as they are open (short-livedcaching)


(Defaultsetting) Cache both open and closed filesas longas cache lasts (long-lived caching);whena closed file is reopened and detectedtobe the same on the server, the workstationwillreuse original cache blocks for fileopen

Max Cache Size. The Max Cache Size parameter lets you set the maximum amount of extended memory that can be used for caching file reads and writes. By default, Client 32 for Windows 95 uses roughly 25 percent of available memory for client­side cache. This setting appears as a zero when you use the default.

For DOS/Windows workstations, Client 32 works from the following table to determine the maximum amount of cache memory, depending on how much free extended memory the workstation has. If you make no setting for Max Cache Size, Client 32 defaults to the following values:


0KBto 384 KB


384KBto 6 MB


6MBto 8 MB

512 KB

8MBto 12 MB

1.5 MB

12MBto 16 MB

2 MB

16MBto 20 MB

3 MB

20MBto 24 MB

8 MB

24MBor more

50percentof extended memory

The Mechanics of Auto-Reconnect

With the default settings for the Auto Reconnect Level and the File Cache Level parameters, Client 32 will restore all files to their actual state before the workstation connection was cleared (or the server went down). For example, if you are logged in on a workstation with auto-reconnect enabled and you are in an application when the server goes down unexpectedly, you will see a message similar to the following:

File Server ServerName is Down. Connection Terminated. Ctrl­Enter to Clear.

As you clear this message (not the connection), you'll see another message similar to the following:

Client32: Please wait while Application retries request to ServerName. To stop waiting, press Enter. NetWare will then return an error and try to reconnect in the background.

If you press <Enter<, the server will return an error and try to reconnect in the background. If you do nothing and the server comes back up, your workstation will be restored to its original condition, depending on how much cache you have and the settings of the DOS Requester and Client 32 parameters.

Clearing Users with Auto-Reconnect Enabled

Now that you have a feel for how auto-reconnect works, we can discuss the special case when you need to clear a user's auto-reconnect connection. NetWare has three server console commands that can be useful when you want to prevent workstations from reconnecting while you are trying to perform some function on the server. These commands are DISABLE LOGIN, ENABLE LOGIN, and CLEAR STATION nn.

DISABLE LOGIN. To prevent auto-reconnect users from reattaching to the server while you are working on it, type DISABLE LOGIN <Enter< at the server console prompt before you clear the connection. You will see a message similar to the following:

1-16-97 7:09:32 pm:   SERVER-4.10-2488

Login is now disabled

With login disabled, users trying to log in will see messages similar to the following (for an NDS connection from DOS):

Your current context is LNA

Enter your password:

Your current tree is: LNA

You are attached to server OFFICE:

LOGIN-4.12-240: This utility was unable to open script file LNA.

LOGIN-4.12-240: This utility was unable to open script file .eliebing.LNA.

On NetWare 4.x workstations running Client 32 with the Graphical Login utility, users will see the client make several attempts to authenticate to the preferred server, but no real error message is displayed when login is disabled. The client will proceed to attach to other resources in the NDS tree as specified in the container or profile login script.

Here's a useful tip for those who are trying to track the login process with Client 32's Graphical Login utility. By default, the login results window stays open only if an error is encountered; otherwise it closes automatically at the end of the login process. If you want this window to stay open so you can see the messages displayed during login, even if there are no errors, you can set a key in the Windows 95 registry as follows. Run the Windows 95 RegEdit program (REGEDIT.EXE is usually found in the C:\WINDOWS directory) and select the following items in this order:




     System Config

       Network Provider

Graphical Login

One of the keys listed to the right for Graphical Login is "Close Results" with a default setting of 1. Double-click on this key and change the setting to 0. The login results window will now stay open when the login process is complete, regardless of whether any errors are encountered.

CLEAR STATION. The CLEAR STATION command clears an active user connection from the server. It works with both NetWare 3.x and 4.x and the syntax is simple:


where nn is the connection or workstation number. The connection numbers are displayed in the MONITOR utility's Active Connections window to the left of the name of the user or object making the connection. You can terminate a connection from this window by highlighting it and pressing the <Del< key. Or you can <Alt<+<Esc< back to the server console prompt and type the CLEAR STATION command, followed by the workstation number; for example:


With either method, the server clears the workstation's connection and all server resources allocated to that connection.

Note: Use the CLEAR STATIONcommandor <Del< key in MONITOR'sActiveConnections windows with caution. Dependingon what theuser is doing at the time, allunsaved work may be lost. Use thisonly asa last resort to remove unwanted clientsfrom the server'sconnection table.

After the connections are cleared, workstation attachments appear as NOT-LOGGED-IN entries in MONITOR's Active Connections window. With login disabled, a workstation with auto-reconnect enabled will still try to reestablish its connection automatically, but the necessary services on the login server won't be available and the user will see the following message:

Client32: Could not auto-reconnect to server ServerName 

because logins have been disabled.

Note that if you don't clear a workstation's connection and a communication failure occurs (such as a broken or unplugged network cable), the workstation will be able to auto-reconnect when the problem is fixed­ even if the login function is disabled.

ENABLE LOGIN. Once you are in a position to allow users to again reattach to the server, type ENABLE LOGIN <Enter< at the server console prompt. You will see the following message displayed at the server console:

1-16-97 7:29:12 pm:   SERVER-4.10-2488

Login is now enabled

Users can now have access to this server's resources again.

* Originally published in Novell AppNotes


The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates