Data Centers

Creating login scripts on your NetWare server

Need control over your users' workstation environment? John Sheesley shows you how to create login scripts on your NetWare server, and he examines several commands that you can use when creating them.

Even though you’re a network administrator, you also have some measure of control over your users’ workstations. There’s little sense in having a network administrator to set up the server and install applications if the user can set up their environment however they want. This quickly causes things to break.

Fortunately, you can exercise some control over workstation environments by using login scripts. In this Daily Drill Down, I’ll show you how to create login scripts on your NetWare server, and I'll examine several commands you have at your disposal.

What are login scripts?
As the name suggests, a login script is a script that executes when a user logs on to the network. The script is a series of commands that change the environment of your user’s workstation, including drive mappings, printer captures, or NDS context. It can also launch external programs.

NetWare supports four kinds of login scripts:
  • Container: Known in NetWare 4.x and 3.x networks as System Login Scripts, these are login scripts that are associated with container objects—usually Organization or Organizational Unit objects. Container login scripts apply to every user object in the container. However, they don’t apply to objects contained within subordinate container objects.
  • Profile: You can use Profile login scripts to create a common login script for a group of users. Profile login scripts belong to the Profile objects that User objects are associated with. A user can only have one Profile login script.
  • User: User login scripts allow you to personalize login scripts right down to the user object level. You can create separate user login scripts for each of your users, but you’ll quickly create a management nightmare. Keep user login scripts to a minimum.
  • Default: The Default login script runs for users who don’t have user login scripts. If you don’t have a user login script on your network, you may notice that after you log on to your server, F: (or the highest non-physical drive letter) is mapped to SYS, and Z: is mapped to SYS:\Public. This is done by the Default login script. You can’t edit the Default login script; however, you can disable it by placing the NO_DEFAULT command in a container or profile object in the NDS tree that the user belongs to.

Login scripts normally execute in the order listed above. If commands contained in two or more scripts conflict, then the commands executed by the last login script to run takes precedence.

How do I create login scripts?
Because login scripts are associated with NDS objects, you create the scripts at the object level in NetWare Administrator. You can use ConsoleOne, but it’s a lot slower and doesn’t offer as many options as NetWare Administrator.

When NetWare Administrator starts, select the object for which you want to create a script. Right-click the object and select Details. When the Properties notebook appears for the object, click the Login Script tab. Enter the login script commands in the Login Script box.

To save time, you can base your login scripts on the samples included with NetWare. You’ll find them in your server’s documentation. You can also find sample login scripts at Novell’s Web site, including Sample Container Login Scripts, Sample Profile Scripts, and Sample User Login Scripts.

To use the samples, just copy them from their original locations by selecting all of the text in the script and pressing [Ctrl][C]. Then, switch to the Login Script page on the Properties page of the object and press [Shift][Ins] in the Login Script box. The commands will then appear in the box, and you can modify them as necessary.

What commands can I include in my login scripts?
NetWare’s command syntax is fairly flexible. Once you’re familiar with the commands and variables that you can use, you can do just about anything you want. In the following sections, I’ll describe the commands and how you can use them. I’ll cover login script variables that you can use to customize your login scripts in upcoming Daily Drill Downs.

The # command allows you to call external programs or batch files to run in conjunction with your login script. You can run any .BAT, .COM or .EXE file that can run from a DOS prompt. To ensure that the external program will run, make sure that it’s in your workstation’s path and that your workstation has sufficient memory and rights to run the program. The syntax for the program is:
# [path] filename [parameter]

where path is the directory path where the file is stored, filename is the name of the program, and parameter is any parameters used by the executable.

You can use the @ command to run external programs from your login scripts. You should use the @ command instead of the # command to run an external program from a login script if the external program will remain open for a while. If you use the # command instead of the @ command on a long-running executable, the login script will remain open until the external program finishes.

Like the # command, you must make sure the external program resides in your workstation’s path and that you have sufficient memory and rights to run it. The syntax for the program is:
@ [path] filename [parameter]

where path is the directory path where the file is stored, filename is the name of the program, and parameter is any parameters used by the executable.

You probably won’t use the ATTACH command unless you still have NetWare 3.x servers on your network. ATTACH makes a bindery connection to another server. NetWare 4.x and 5.x servers don’t require this command to make attachments because users authenticate directly to the NDS tree, not a particular server.

If you use the BREAK command in a login script, the user can press [Ctrl][C] or [Ctrl][Break] to abort the script. To use the BREAK command, type BREAK ON. You can disable it later by including a BREAK OFF command. The default setting for login scripts is BREAK OFF.

The CONTEXT command sets a user's current context in the NDS tree. It’s very similar to the CX utility that a user can run from the DOS prompt. You can enter a complete context name to set a user’s context, or you can use periods to move the context up toward the root of the tree.

The format for the CONTEXT command is very simple. In your login script, add a line that says CONTEXT .newcontext, where .newcontext is the distinguished name of the target context.

You can use the DISPLAY command to show the contents of a text file. DISPLAY shows all of the characters in the file, including any control codes used by printers and word processors. To use the command, type DISPLAY path\filename where path is a workstation drive letter or a full directory path beginning with the NetWare volume name and filename is the full name of the file that you want to display.

The DRIVE command allows you to change the default drive. If you don’t include the DRIVE command in the login script, the default drive will be set to the first network drive available. Normally the default drive is assigned to the user's home directory upon login. You can specify either a drive letter or a drive number in the DRIVE command. The basic syntax of the command is DRIVE drive |*n where you enter a specific letter in place of drive, or replace n with a drive number. The number n represents the nth network drive assigned. Using numbers rather than letters allows the default drive to automatically reorder itself as drive mappings are deleted or added.

The EXIT command terminates the login script. You can use this command in the middle of an IF…THEN loop to stop the login script from continuing. You don’t need to place it at the end of a login script to signify the end of the script.

FDISPLAY works the same as the DISPLAY command. However, the FDISPLAY command only displays text—it won’t display any extended ASCII characters. For extended ASCII characters, you must use DISPLAY to show the text of a word processing file when the user logs on. The syntax is also identical to DISPLAY.

The FIRE and FIRE PHASERS command plays a phaser sound on the user’s workstation. In the good 'ol DOS days, FIRE PHASERS was just a rapid beep, but now it plays the PHASERS.WAV sound file. You can also play other .WAV files with the FIRE command. The syntax for the command is FIRE n sound where n is the number of times that you want the sound to play and sound is the name of the sound file that you want to play (if you want to use something other than PHASERS.WAV).

As your login scripts become more complex, you may create different sections to perform specific tasks. Each section begins with a label. You can use the GOTO command to force the login script’s execution path to change from one section to another. The syntax for the command is GOTO label where label is the start of the section to which you want to branch.

Be very careful when using the GOTO command. It’s very easy to create "spaghetti" login scripts that are hard to read and debug. Also, using the GOTO command within nested IF…THEN commands can cause errors or unexpected results.

The IF…THEN command is one of the most powerful and common statements you’ll use. It can also be the most confusing when trying to decipher login scripts. The IF…THEN command enables you to allow the login script to do different things based on conditions that the statement checks for. For example, you could check to see if a user is a member of a certain group and change his or her drive mappings accordingly.

The syntax for the IF…THEN command is very simple, but the rules surrounding it are what make it confusing and complex. The syntax for IF…THEN is

IF condition [AND/OR condition] THEN

command sequence


command sequence]


where condition is the condition you’re testing for and command sequence is the list of commands you want to occur if the condition is true. Conditions following the ELSE command occur if the condition is false. The ELSE command and the commands that follow it are optional. The END command is optional unless you have more than two lines in your IF...THEN command, including an ELSE statement. However, you may want to make a habit of using END at the end of all IF…THEN routines because using it makes reading IF…THEN commands much easier.

When setting conditions, there are a few things you must keep in mind. First, when you're checking the value for a condition, the login script treats the value as a string variable, even if you enter a numeric value. If you want to check for a numeric value, you must use the VALUE modifer. Second, you must enclose the values for conditions in quotation marks.

You can check the values of the conditions by using standard mathematical symbols, including those shown in Table A.

Table A
= Equals
< > Not equal
> Greater than
>= Greater than or equal to
< Less than
<= Less than or equal to
Standard mathematical symbols used to check values of the conditions.

In addition to mathematical equations, you can set logical conditions such as checking to see whether a person is a member of a certain group. To do so, use the MEMBER OF or NOT MEMBER OF commands.

You can use the AND and OR commands to narrow your conditions. As you can probably guess, you use AND when you want to have two or more conditions met. Use OR if you have two or more conditions that are satisfactory, and you don’t care which is met.

You can also nest IF…THEN commands up to 10 levels deep. Nesting refers to the placement of IF…THEN commands inside of another IF…THEN command. If the condition of the first IF…THEN command is satisfied, then the login script tests for the second IF…THEN command. When that condition is satisfied, then the commands execute normally. An example is:

 WRITE “Your wish is my command”

As I mentioned when discussing the GOTO command, you don’t want to issue a GOTO out of a nested IF…THEN statement.

You probably won’t use the INCLUDE command, but it can be a very handy command. It’s also one that can be quite confusing from an administrative point of view. You use the INCLUDE command to execute another object's login script as a part of the current login script. Doing so can save you time retyping another login script, but it can be an administrative headache when you have to make changes to your scripts. The syntax for the command is INCLUDE object_name where object_name is the name of the object that contains the login script you want to include.

You can include text files as well as login scripts from other objects. If you want to use a text file, put the path and filename information in place of the object.

As you can probably guess, the LASTLOGINTIME command displays the last time the user logged in. There are no options to the command, just issue it by itself.

You’ll probably use the MAP command more than most commands in your login scripts. The MAP command allows you to create drive letters associated with volumes and directories on your NetWare servers. You can also create search maps. A search mapped drive is one that the user’s computer will look at to execute a command if the command doesn’t exist on the user’s current directory.

The MAP command is very easy to use and has several options that give you more control over the user’s environment. The syntax for the MAP command is MAP [[options]|[parameters][drive:=path].

The path statement is where you type the source path (such as SNOWBALL_SYS:\) where the mapped drive will point. You’ll replace the drive statement with the physical drive letter (such as Z:) that you want to map the path to. When mapping to an NDS object, use the object's fully distinguished name preceded by a leading period (.), such as .SNOWBALL.TPG.

Instead of a drive letter, you can use an asterisk followed by a number, such as *2. Doing so tells the MAP command to map the second available drive letter after the primary network drive letter. In this example, if the primary drive was F:, *2 would be G:. The advantage of this syntax is that the mapping will automatically change as the drive letters change. This can make things simpler for machines that may have more physical drive letters due to larger hard drives with more partitions, ZIP drives, multiple CD-ROMs, JAZ drives, and so forth.

Options that you can use for the MAP command include:
  • DISPLAY: This option determines whether drive mappings display on the screen when the user logs on. You can set Display to either ON or OFF. The default setting is ON.
  • ERRORS: This option determines whether MAP error messages display when the user logs on. You can set this option to either ON or OFF. The default setting is ON. If you want to turn the errors off, you must place MAP ERROR OFF before any other MAP commands in the login script.

Parameters that you can use with the MAP command include:
  • C or CHANGE: This parameter changes a search drive mapping to a regular mapping, or changes a regular mapping to a search drive mapping.
  • DEL: This parameter deletes a drive mapping. When a mapping is deleted, the old drive letter becomes available for other mapping assignments, or it's left blank.
  • INS: This parameter inserts a drive mapping between existing search mappings.
  • N or NEXT: When used without specifying a drive number or letter, this parameter maps the next available drive.
  • P or PHYSICAL: This parameter maps a drive to the physical volume of a server rather than to the volume object's name. You’ll need this parameter if a volume object name in your NDS tree conflicts with a physical volume name.
  • R or ROOT: This command maps a drive letter to a subdirectory on your server’s volume. It also makes it appear that there are no directories higher than the current subdirectory. This is known as a fake root. You may need this because some applications want to look at a root directory, not a subdirectory. A Windows NT/2000 workstation’s native environment forces a map root on all drives. To prevent a forced map root in a Windows NT/2000 environment, set the MAP ROOT OFF = 1 environment variable.

You should use the NO_DEFAULT command in a container that contains objects for which you don’t want the Default login script to run.

As the name suggests, the PAUSE command pauses the execution of the login script. You can use the PAUSE command to stop a script, giving users the opportunity to read any messages you want to display at login time. You can also use this command to pause a login script when you create it so you can debug any errors in your script. When the PAUSE command executes, the message "Strike any key when ready ... " appears on the workstation screen. NetWare Login then waits for a key to be pressed before it executes the rest of the login script.

You can use the PROFILE command in a container login script to set or override a user's assigned profile script. Because a user can normally only execute one profile login script, this command is useful for switching profile login scripts based on conditions. The syntax for the command is PROFILE profile_object where profile_object is the name of the profile object that contains the profile login script you want to use.

You can use the REMARK command to put comments in your login scripts. Doing so makes deciphering the login script easier later. There are several different variations to the REMARK command. The syntax for the REMARK command looks like:

REMARK comment
REM comment
* comment
; comment

where comment is the actual comment you want to place about the login script. You must place the REMARK command on its own line. You can’t place a comment at the end of another login script command. Also, you must start each line of a comment with the REMARK command, unlike some programming languages you may be familiar with.

You’ll probably never use the SCRIPT_SERVER command. It’s only for older NetWare 2.x and 3.x users that connect using bindery mode. This command has no effect on NDS logins.

The SET command sets a workstation’s environment. It’s much like the SET command that you use in a workstation’s AUTOEXEC.BAT and does the same thing. Novell actually recommends that you use AUTOEXEC.BAT to set environment variables rather than the SET command in login scripts. The syntax for the SET command is SET setting=”variable” where setting is the environment variable you want to set and variable is the setting you want to use. An important thing to remember is that the variable must be enclosed in double quotes.

As you’ve probably noticed, when your workstations log on to your server, your workstation automatically updates its time from the server. You can disable this action in the login script by using the SET_TIME command. The syntax for the SET_TIME command is SET_TIME ON/OFF.

The default setting is ON. If you enter SET_TIME OFF into your login script, the workstation won’t update its time.

The SHIFT command can be quite confusing. This command changes the order in which %n login script variables are interpreted. I’ll explain how login script variables work in an upcoming Daily Drill Down.

The SHIFT command allows you to shift up to 10 login script variables from %0 to %9. You can add SHIFT with a positive or negative number to move the variables in either direction. For example, SHIFT -4 moves each %n variable four positions to the right. The syntax for the SHIFT command is SHIFT n where n is the number of places that you want the variable to shift. The default value for the SHIFT command is 1.

The TERM command is another command that you probably won’t use very often. Novell states that this command is normally used only for Novell Application Launcher scripts. The TERM command stops a login script and returns an error code. This is most useful when used with the IF…THEN command.

Because TERM stops the login script, it’s best to put this command either at the end of the login script or at a place within the script where you intend for the execution to stop. If you use the TERM command in a container login script, it prevents subsequent profile or user login scripts from running. Likewise, if you put TERM in a profile login script, it prevents the user login script from running.

The syntax for the TERM command is TERM n where n is the error level you want to return. You can set any error level between 000 and 999.

The TREE command attaches the user to another NDS tree within the network and allows the user to access resources on those trees. You can only use the TREE command with clients that support multiple NDS tree attachments.

The TREE command can be quite confusing. When you use the TREE command, all NDS object references in subsequent script commands apply to the new NDS tree specified in the TREE command. You can include multiple TREE commands within a login script, either to attach to additional trees or to switch the login script's focus back to the original NDS tree. The syntax for the TREE command is TREE NDS_tree[/context_name[;password]] where NDS_TREE is the name of the NDS tree that you want the user to attach to, context_name is the user's Distinguished Name for the new NDS, and password is the password for the user ID.

If you don’t include the context name, NDS prompts the user for a complete name when the TREE command executes. If the username and password on the target NDS tree are the same as the one that the user logged into the current tree, you can omit the password and not be prompted for it.

It's not a good idea to include passwords in login scripts. Another user can view the login scripts and discover the passwords. It’s best to leave the password option blank. When the TREE command executes, the user will be prompted to enter a password.

The WRITE command displays messages on the workstation screen when a user logs on to the network. Unlike the DISPLAY or FDISPLAY command, the WRITE command only displays the text that you hard code into the login script, not text loaded from a file. The syntax for the WRITE command is WRITE "[text][%variable]" [;][variable] where text contains the text you want to display and variable represents variables you can use to customize the output of the message. You must enclose any text within quotation marks.

There are several ways to display variables in the text message. The way you enter the variable in the WRITE command determines how the variable will appear on screen. If you type the identifier variable with no special punctuation, only the variable is displayed on the screen. You can also use a [%] sign before the variable. If you do this, you can include the variable with other text inside of quotation marks to form a sentence.

You can use a few special characters in the WRITE command, including those shown in Table B.

Table B
\r Creates a carriage return
\n Starts a new line of text
\" Displays a quotation mark
\7 Makes an audible beep
The WRITE command's special characters.

You can form compound strings using text strings and variables using several different operators. Some of the operators you can use include those shown in Table C.

Table C
; Join text strings and variables together when the variables aren’t within quotation marks.
* Multiply
/ Divide
% Modulus
+ Add
- Subtract
>> Shift right
<< Shift left
Operators used to form compound strings.

Login scripts can be very powerful and very useful. You can use them to control a user’s environment and to enforce basic system configurations such as drive mappings and printer captures. In this Daily Drill Down, I've shown you how to create login scripts and examined several of the commands you can use when creating them.
If you have any login scripts on your network that you think would be useful to others or that you think are particularly creative, e-mail them to us. We’ll share them with other subscribers to TechRepublic in future Daily Drill Downs. Make sure that you send them in flat ASCII format. Also, make sure that you include detailed documentation about the purpose of the script and how you’ve used the commands.

John Sheesley has been supporting networks since 1986, when he got his hands on NetWare 2.2. Since then, he’s worked with the Jefferson County Police Department in Louisville, KY and the Genlyte-Thomas Group. John’s been a technical writer for several leading publishers, including TechRepublic, The Cobb Group, and ZDJournals. If you’d like to contact John, send him an e-mail .

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox