Practical Networking

NDS Login Scripts

Chad Sexton

Login scripts contain commands for setting up a user's workstation environment when the user logs in to the network. You can use login scripts to map network drives and search drives to volumes and directories, to display messages during the login process, and to run programs.

In IntranetWare and NetWare 4, four types of login scripts are available; three of these login scripts are properties of Novell Directory Services (NDS) objects, and the fourth login script is a function of the login utility that a workstation's Novell client software runs. This article explains which login scripts run when a user logs in to an IntranetWare or NetWare 4 network. This article also describes how to create a profile login script and discusses conflicts that can occur between login scripts.

THE HIERARCHY OF NDS LOGIN SCRIPTS

IntranetWare and NetWare 4 support four login scripts:

When a user logs in to the network, the user's Novell client software processes login scripts in the order listed above. First, this client software runs the container login script if you have created one for the container object in which the User object resides. The Novell client software then runs the profile login script if you assigned the User object to a Profile object. Next, the Novell client software runs the user login script if one has been created for the User object. If the User object does not have a user login script, the Novell client software runs the default login script.

If you want to prevent the default login script from running, you can add the NO_DEFAULT or EXIT command to the container or profile login script. The NO_DEFAULT command simply prevents the default login script from running, but the EXIT command prompts the container or profile login script to end as soon as it reaches this command. After exiting the container or profile login script, the Novell client software cannot run any other login scripts, including the default login script.

NDS LOGIN SCRIPTS IN ACTION

You can see how login scripts work by examining the NDS tree for a fictional company called XYZ. As shown in Figure 1, the Marketing container object, for which a container login script has been created, is Fred's parent container object. In addition, Fred's User object has been assigned to the Graphics Profile object, and Fred has created his own user login script. When Fred logs in to the network, the container login script for the Marketing container object runs, followed by the profile login script for the Graphics Profile object. Finally, Fred's user login script runs.

As you know, a user inherits rights from every container object that resides above the user's parent container object in the NDS tree (unless these rights are blocked). Login scripts, however, do not work this way: If a container login script has been created for a container object that resides above a user's parent container object in the NDS tree, this script does not run when the user logs in to the network.

For example, a container login script has been created for both the XYZ container object and the Marketing container object. (See Figure 1.) Because the Marketing container object is Wilma's parent container object, the Marketing container login script runs when Wilma logs in to the network, but the XYZ container login script does not run. If you want to give all users the same workstation environment settings, you should assign the same container login script to each container object in which one or more User objects reside.

CREATING A PROFILE LOGIN SCRIPT

You have probably grouped users who are in the same department in the same container object. If you want to create a specialized login script for a particular group of users, however, you may need the flexibility that a profile login script provides.

You can use a profile login script to assign workstation environment settings to a particular group of users in one container object. Because a Profile object does not have to reside in a user's parent container object, you can also use the profile login script to assign workstation environment settings to users in multiple container objects. For example, you might create a profile login script to map network drives that certain users might need in addition to the drives mapped by the users' container login script.

To create a profile login script, you use the NetWare Administrator (NWADMIN) utility to create a Profile object and login script. You then associate the Profile object with particular User objects, enabling the Novell client software running on each user's workstation to run the profile login script you have created.

To associate a Profile object with a User object, you must complete the following steps:

1. Launch the NWADMIN utility, and select the User object.

2. From the Object pull-down menu, select the Rights to Other Objects option. The Search Context dialog box appears, prompting you to enter the name of the NDS tree on which you want to search for the User object's rights.

3. After you enter the name of the appropriate NDS tree, click the OK button. The Rights to Other Objects page for the User object you selected appears.

4. Click the Add Assignment button. The Select Object page appears. You can scroll down the Available Objects list to find the Profile object, or you can browse for this object in another NDS context.

5. After you select the appropriate Profile object, click the OK button. The Rights to Other Objects page appears again, and the Profile object you selected now appears in the User object's Assigned Objects list on this page. Ensure that the Profile object is highlighted so you can grant the User object the necessary rights to the Profile object.

6. Under the Object Rights heading, click the Browse box to grant the User object the Browse right to the Profile object. Then under the Property Rights heading, select the All Properties option, and click the Read box to grant this User object the Read right to all of the Profile object's properties.

7. Click the OK button, and double-click the User object. This object's Details page appears.

8. Click the Login Script button. The Login Script page appears.

9. Click the button to the right of the Profile field. You can scroll down the Available Objects list to find the Profile object, or you can browse for this object in another NDS context.

10. After you select the appropriate Profile object, click the OK button.

As mentioned earlier, a profile login script runs after the container login script and before the user or default login script. For example, no container login script has been created for the Publications container object in company XYZ. (See Figure 1.) Because Betty's User object is associated with the Sales Profile object, which has a login script that includes the EXIT command, only the Sales profile login script runs when Betty logs in to the network.

AVOIDING CONFLICT

Because one to three login scripts run every time a user logs in to the network, conflicts between these login scripts can occur. After the first login script runs, each subsequent login script can remap network drives and change settings that previous login scripts have implemented.

As mentioned earlier, the default login script runs if a User object does not have a user login script and if the container login script and the profile login script do not include the NO_DEFAULT or EXIT commands. If you want the default login script to run when a user logs in to the network, you should ensure that this login script does not conflict with the other login scripts you have created.

For example, when Wilma logs in to company XYZ's network, the Marketing container login script runs. (See Figure 1.) This login script maps the F: drive on Wilma's workstation to her home directory on the network by including the following command:

MAP F:=SERV1\VOL1:\HOME\%LOGIN_NAME

The Marketing container login script does not include the NO_DEFAULT command or the EXIT command, and Wilma has not been assigned a profile login script. Because Wilma does not have a user login script, the default login script runs. However, this login script maps the first network drive on Wilma's workstation to the SYS volume on her preferred server by including the following command:

MAP*1:=SYS:

On Wilma's workstation, the first network drive has been defined as the F: drive. (The first network drive is defined in the Network control panel or in the NET.CFG file for the Novell client software running on a user's workstation.) As a result, the default login script remaps Wilma's F: drive. If Wilma does not know how to map another network drive to her home directory on the network, she cannot access the files in this directory.

CONCLUSION

With IntranetWare and NetWare 4, you can use four types of login scripts to customize a user's workstation environment. However, you do need to avoid conflicts between login scripts and look for these conflicts when users encounter problems with their workstation environment.

If you have any login script tips that you want to share, please send an e-mail message to practical@niche-associates.com. You can also send comments or suggestions for future columns to ensure that "Practical Networking" meets your needs.

For example, a recent column explained how to send a network broadcast message from Windows 95. (See "Practical Networking: New Moves in Windows 95," NetWare Connection, Aug. 1997, pp. 40-42.) Several readers sent e-mail messages saying that when they right-clicked a server icon in Network Neighborhood, as the article described, the pop-up menu did not include the Send Message option. This option is missing because the ability to send a network broadcast message from Network Neighborhood was first available in IntranetWare Client 2.11 for Windows 95. If you want to enable the option on users' workstations, you can download the latest version, IntranetWare Client 2.2 for Windows 95, free from http://www.novell.com/novellsw/platform.html.

If you upgraded users' workstations from Windows 3.1 to Windows 95 and installed IntranetWare Client 2.11 for Windows 95 or higher, the upgrade process disabled NetWare User Tools, and Network Neighborhood now includes drive-mapping and broadcast-message features. If users prefer to use NetWare User Tools, you can reenable it by adding the following lines to the NETWARE.INI file (which is usually located in the Windows folder) on the users' workstations:

[Restrict]
UserTool=1

After you add these lines and restart the workstations, users can run NetWare User Tools. In the NetWare User Tools window, users can click the Message button, type a network broadcast message in the space provided, and select the user or users to send this message to.

Chad Sexton works for Niche Associates, which specializes in technical writing.

NetWare Connection, November 1997, pp. 34-35