Troubleshooting Login Scripts.

(Last modified: 08Jul2005)

This document (10012087) is provided subject to the disclaimer at the end of this document.

goal

fact

Formerly TID 1203151

Novell NetWare for Small Business 4.2

Novell NetWare for Small Business 4.1

Novell NetWare 3.12

Novell NetWare 4.11

Novell NetWare 5.0

symptom

Not getting expected drive mappings from login script.

Losing PATH statements after login .

Could not execute external command <command>.

Part of login script not executing.

fix

Introduction:
Login scripts are the set of instructions that LOGIN.EXE or the GUI-Login executes when a user logs in. A login script is simply a text file that is interpreted and run line by line. Though login scripts are useful in setting up drive mappings, search mappings, the users printing environment, and displaying important messages and other commands, they can sometimes be a source of frustration when they don't work as expected. This document will help the reader recognize and troubleshoot some of the most common login script problems. In order to troubleshoot a login script, it is important to know where the login script text files are located and in which order the login scripts run.

NetWare 3.1x Networks

In 3.1x networks, there are three types of login scripts that can be used--the system login script, the user login script, and the default login script. These scripts are executed in the following order: If a system login script exists, it will execute first. Next, the user login script will run if it exists. If no user login script has been defined, a default login script will run.

The system login script can be found in the SYS:PUBLIC directory as a file called NET$LOG.DAT. This file can be edited through any ASCII text editor. The file attributes probably need to be modified to allow r/w-access. The user login script is found in the user's mail directory as a file called LOGIN and can also be edited with a text editor. The default login script is embedded in LOGIN.EXE and cannot be modified.

Each script will execute without regard for what has been done in previously run scripts. For example, If the default login script runs after a system login script, it may overwrite mappings the system login script just made. The default script can be avoided by doing one of the following:
1) Use the EXIT script command. The EXIT command in the system login script will cause LOGIN.EXE to immediately exit without executing any further instructions in the current or subsequent scripts. Caution should be exercised when using the EXIT command, since placing this ahead of necessary mappings, such as to SYS:PUBLIC could render the system unusable.

2) Create a "do nothing" user login script. A "do nothing" user login script is one which does nothing consequential. For an example, the script may contain nothing more than a carriage return, or a WRITE " " statement.

3) (For 3.12 networks only.) LOGIN.EXE supports the script command NO_DEFAULT. This command, placed in the system login script will prevent the default script from running, even if no user script exists.

NetWare 4.1 Networks

In 4.1 networks, there are four types of login scripts--system (container), profile, user, and default. They execute in the order listed. As in 3.x networks, if no user script exists, the default script will execute. To prevent the default script from running, use the same options as listed above in the NetWare 3.x section. Note that the NO_DEFAULT command can be placed in the system (container) script or the profile script.
To create or edit the login script using the NetWare Administrator utility, double click the container, profile, or user desired (or right click and then click details of the aforementioned desired object) and then click the login script button to bring up the edit window.
Certain NetWare Directory Services (NDS) rights must be granted to the users in order to use the login scripts. For whichever script that a user needs to run, they must be a trustee of the object and have at least the read right to the login script property, which will automatically give the user the compare right. This is sufficient to run the login scripts. Browse rights are not necessary. The Browse right only gives the object the right to be seen by another object. You don't have to see the login script in order to run it.

The login scripts in NDS are located within the NDS itself and should not be changed by any other means than through the NETADMIN or NetWare Administrator utilities.

Troubleshooting Login Scripts

A majority of the problems one will find after running a login script deal with mapping drives and capturing printers. Usually, these problems can be attributed to syntax and spelling errors. Correcting spelling errors and using variables in the right way (e.g. putting quotes around a login name being tested in an IF..THEN condition) resolve many problems. Login script variables and their usage can be found in the documentation Installation and Upgrade reference manual (NetWare 3.12) or Supervising the Network I (NetWare 4.1). An expanded list including NDS properties available as login variables can be found in the May 1995 edition of Novell AppNotes.

The best way to troubleshoot the above mentioned problems is to do one or more of the following:

1) Set MAP DISPLAY and MAP ERRORS to ON in the login script. Many administrators set these parameters to OFF, thus hiding many mapping errors which occur during login script execution. By setting them to ON, the errors will display, often providing clues as to why a certain command did not execute as expected. After seeing that the login script performs all map commands without error, the MAP DISPLAY and MAP ERRORS parameters can be returned to the OFF position.

2) Use the WRITE or MAP commands together with the PAUSE command prior to the script command which doesn't work as expected. For example, if the login script didn't seem to be getting into an IF..THEN statement, put both a WRITE and a PAUSE statement immediately before the IF..THEN statements to verify that the script executed to that point. Then, place a WRITE and PAUSE inside the IF..THEN to see if it gets past the IF correctly. It would also be helpful to have the WRITE statement give the value of the variables being tested to make sure that the variables are correct going into the script (e.g. WRITE "This is the login name: %LOGIN_NAME"). The same type of thing can be done using the MAP command with a PAUSE. This is useful to determine when and where a certain mapping was made in a login script.

3) Make a test login script file either on the local drive or a network drive using any DOS text editor. Test this script file by using the /S parameter for LOGIN.EXE (e.g. LOGIN /S <drive>:\<filename> <servername>/<username>). If this login script works correctly, start cutting and pasting the statements in this login script into the login script that doesn't seem to be working correctly. This way, problems in login scripts can be dealt with by elimination.

Other Common Login Script Problems

LOSING PATH STATEMENTS AFTER LOGIN: After each log in, the user would lose a part of the path specified in the AUTOEXEC.BAT. The user had PATH statement in AUTOEXEC.BAT and then had mapped some search drives in the system login script (MAP S1:= MAP S2:= ). PATH statements are set up as search mappings when logged onto the network starting with s1, s2, and so on. When you specifically MAP (S1:=), then you overwrite the existing search mapping (PATH). Solution: Doing a MAP INS on the search drives will push the existing statements down the line without overwriting. Using MAP INS S16:= will append the map statements to the end of the line without overwriting those at the beginning.

COULD NOT EXECUTE EXTERNAL COMMAND <COMMAND>:. This error occurs with external commands trying to run inside a login script, such as the CAPTURE.EXE command. To troubleshoot this problem, make sure the COMSPEC is set. Then, make sure LOGIN.EXE is being swapped out correctly.

EXIT COMMAND DOESN'T WORK. Make sure the syntax is right. EXIT "<path:command>" with the quotes is the right syntax. Be careful the path and command you put in the quotes are not more than 14 characters long. The early versions of LOGIN.EXE in 3.1X and the LOGIN.EXE in 4.1 don't support more than 14 characters in the path. Also, remember that EXIT will exit you clear out of the login script, not allowing any other login scripts to run. If there is a user or profile login script that a user needs to execute, you should not use EXIT to get out of the system/container login script.

LOGIN SCRIPT DOING UNEXPECTED THINGS. Make sure there are no viruses on the computer. Viruses have caused numerous strange problems with login scripts that have previously executed or should now execute correctly. Sometime virus scanners cause the same symptom. Try uninstalling the virus scanner and see if that makes a difference. Also, temporarily delete any TSRs, as some have been known to cause login problems. Using an ATTACH command to create an attachment to another 4.1x server in the same tree can also cause unexpected results such as intermittent premature termination of the login script. The ATTACH command makes a bindery connection which causes any previous NDS connections to that server to be destroyed. Using CAPTURE with the Server parameter will also cause a bindery attachment to occur.

Conclusion

Login scripts should not be a source of confusion and frustration for a network administrator. When written properly, with the right syntax, and in a virus-free environment, login scripts are practically failproof. Hopefully these few steps discussed will aid in finding the few problems that occur in login scripts and will help improve login script troubleshooting skills.

document

Document Title:	Troubleshooting Login Scripts.
Document ID:	10012087
Solution ID:	4.0.880992.2190832
Creation Date:	16Jun1999
Modified Date:	08Jul2005
Novell Product Class:	Connectivity Products End of Life Management Products NetWare Novell BorderManager Services Novell eDirectory

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.