Using Login Scripts on NetWare Networks

On NetWare networks (version 3.x or using the bindery), the system login script named NET$LOG.DAT is stored in the PUBLIC directory on the server. Individual user scripts are stored in their MAIL subdirectories. The network administrator can use SYSCON (or NWADMIN for VLM) to edit login scripts for any NetWare-compatible client running under Windows 95.

Login scripts are stored differently on NetWare 3.x servers (using bindery services) versus NetWare 4.x servers (using NDS). On a bindery server, the System login script is stored in the NET$LOG.DAT file in the PUBLIC directory, and User login scripts are stored in the LOGIN file in MAIL subdirectories that correspond to the users' internal IDs. On an NDS server, the Container, Profile, and User login scripts are stored in the NDS database as properties of those objects.

The issues related to running login scripts depend on whether the computer is configured with Client for NetWare Networks or uses a Novell-supplied network client.

Running Login Scripts with Client for NetWare Networks

If the computer is running Client for NetWare Networks, the special Windows 95 login script processor runs the login script after the user completes entries in the network logon dialog box during system startup. Microsoft Client for NetWare Networks makes only bindery connections. When it connects to a NetWare 4.x server, the server must be running bindery emulation, so that the login scripts can be accessed in the same way as on a bindery server. If bindery-type login script files aren't available, you must use SYSCON from a NetWare 3.x server to connect to the NetWare 4.x server and create bindery-type System and User login scripts.

The Windows 95 login script processor runs NetWare 3.x system and user login scripts, using commands in these scripts, such as MAP and CAPTURE, to make global changes to the system environment. For example, a script might include SET statements or PATH statements to specify search drives.

The login script appears in a window if the user's login script contains the WRITE, DISPLAY, FDISPLAY, PAUSE, or WAIT commands.

The Login Script Processor window

Any NetWare or MS-DOS command (in conjunction with NetWare login script commands) can be used in a login script except those that load TSRs. The Windows 95 login script processor operates in protected-mode, so loading real-mode TSRs from a login script is not possible because login scripts are run after all real-mode actions are completed at system startup. Any TSR that is run from a login script is loaded in a single VM, which is subsequently shut down when login script processing is completed. In these cases, the login script processor displays an error message.

For loading components such as backup agents, protected-mode equivalents in Windows 95 can be used instead of running TSRs. If you need to run a TSR to support an application, use one of the options described in the following table.

Loading TSRs with Client for NetWare Networks

What the TSR must support

Where to load the TSR

With NDIS 3.1 drivers:

All applications created for MS-DOS or Windows, without IPX/SPX support

AUTOEXEC.BAT

All Windows-based applications that require IPX/SPX support1

WINSTART.BAT in the Windows directory

Any MS-DOS – based application that requires IPX/SPX support2

Load the TSR at the command prompt before running the application

With ODI drivers:

All applications created for MS-DOS or Windows with IPX/SPX support

After the entry that loads IPXODI in AUTOEXEC.BAT


1 The IPX/SPX-compatible protocol (NWLINK) is loaded after real mode is complete but before login scripts are processed, so this protocol is available for TSRs loaded from WINSTART.BAT.

2 The TSR must be loaded in each separate VM for each application that requires that TSR before the application is loaded. This can be done in a batch file used to run the application.

The network administrator might want to warn users that, in the following circumstances, the login script processor can display special windows and messages, and that this is not an error condition:

The following list presents some tips for testing and running login scripts with Client for NetWare Networks:

Note The Windows 95 login script processor can handle any documented NetWare login script commands. Any undocumented variations on NetWare commands might not be processed as legal statements.

You can make persistent connections (using the same drive letter each time) to NetWare volumes and directories by using the Windows 95 user interface. Using persistent connections eliminates the need for some NetWare MAP commands in login scripts. However, if persistent connections are made to a server, you should avoid using the ATTACH command in login scripts. For information about making persistent connections, see "Connecting to Drive and Printer Resources" later in this chapter.

Client for NetWare Networks also differs from NETX and VLM in that it does not map the first network drive to the logon directory of the preferred server. All subsequent connections to NetWare servers must be made by using Windows 95 tools.

Running Logon Scripts with Novell-Supplied Clients

If a computer is running the Novell-supplied NETX or VLM networking client, login scripts are processed as they were before Windows 95 was installed.

With NETX or VLM, login scripts are run during system startup after real mode at the command prompt before Windows 95 switches to protected mode. Therefore, all statements and TSRs will run as expected and be available globally for all applications created for Windows or MS-DOS.

Important

Users running a Novell-supplied client should always log on to the NetWare server before running Windows 95. Otherwise, many operational problems will occur. For example, if a user instead logs on at command prompt while already running Windows 95, then all the drive mappings created by the login scripts will be local only to that VM.