NDS Login Scripts
Articles and Tips:
01 Nov 1997
Login scripts contain commands for setting up a user's workstation environmentwhen the user logs in to the network. You can use login scripts to map networkdrives and search drives to volumes and directories, to display messagesduring 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 utilitythat a workstation's Novell client software runs. This article explainswhich login scripts run when a user logs in to an IntranetWare or NetWare4 network. This article also describes how to create a profile login scriptand discusses conflicts that can occur between login scripts.
THE HIERARCHY OF NDS LOGIN SCRIPTS
IntranetWare and NetWare 4 support four login scripts:
Container login scripts, which run for all User objects in a container object, such as an Organizational Unit (OU) object.
Profile login scripts, which run for all User objects that are assigned to--and have been granted the necessary rights to--a Profile object.
User login scripts, which run for only one User object.
Default login scripts, which run as part of the login utility that a workstation's Novell client software runs. (For example, a DOS workstation runs the LOGIN.EXE utility, and a Windows 95 workstation runs the LOGINW95.EXE utility. All Novell login utilities implement a default login script.)
When a user logs in to the network, the user's Novell client softwareprocesses login scripts in the order listed above. First, this client softwareruns the container login script if you have created one for the containerobject in which the User object resides. The Novell client software thenruns the profile login script if you assigned the User object to a Profileobject. Next, the Novell client software runs the user login script if onehas been created for the User object. If the User object does not have auser login script, the Novell client software runs the default login script.
If you want to prevent the default login script from running, you canadd 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 endas soon as it reaches this command. After exiting the container or profilelogin 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 fictionalcompany called XYZ. As shown in Figure 1, theMarketing container object, for which a container login script has beencreated, is Fred'sparent container object. In addition, Fred's Userobject has been assigned to the Graphics Profile object, and Fred has createdhis own user login script. When Fred logs in to the network, the containerlogin script for the Marketing container object runs, followed by the profilelogin script for the Graphics Profile object. Finally, Fred's user loginscript runs.
Figure 1: You can assign container, profile, and user login scripts to users or groups.
As you know, a user inherits rights from every container object thatresides above the user's parent container object in the NDS tree (unlessthese rights are blocked). Login scripts, however, do not work this way:If a container login script has been created for a container object thatresides above a user's parent container object in the NDS tree, this scriptdoes not run when the user logs in to the network.
For example, a container login script has been created for both the XYZcontainer object and the Marketing container object. (See Figure 1). Because the Marketing container object is Wilma's parent containerobject, the Marketing container login script runs when Wilma logs in tothe network, but the XYZ container login script does not run. If you wantto give all users the same workstation environment settings, you shouldassign the same container login script to each container object in whichone or more User objects reside.
CREATING A PROFILE LOGIN SCRIPT
You have probably grouped users who are in the same department in thesame container object. If you want to create a specialized login scriptfor a particular group of users, however, you may need the flexibility thata profile login script provides.
You can use a profile login script to assign workstation environmentsettings to a particular group of users in one container object. Becausea 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 environmentsettings to users in multiple container objects. For example, you mightcreate a profile login script to map network drives that certain users mightneed 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 associatethe Profile object with particular User objects, enabling the Novell clientsoftware running on each user's workstation to run the profile login scriptyou have created.
To associate a Profile object with a User object, you must complete thefollowing steps:
Launch the NWADMIN utility, and select the User object.
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.
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.
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.
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.
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.
Click the OK button, and double-click the User object. This object's Details page appears.
Click the Login Script button. The Login Script page appears.
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.
After you select the appropriate Profile object, click the OK button.
As mentioned earlier, a profile login script runs after the containerlogin script and before the user or default login script. For example, nocontainer login script has been created for the Publications container objectin company XYZ. (See Figure 1.) Because Betty'sUser object is associated with the Sales Profile object, which has a loginscript that includes the EXIT command, only the Sales profile login scriptruns when Betty logs in to the network.
AVOIDING CONFLICT
Because one to three login scripts run every time a user logs in to thenetwork, conflicts between these login scripts can occur. After the firstlogin script runs, each subsequent login script can remap network drivesand change settings that previous login scripts have implemented.
As mentioned earlier, the default login script runs if a User objectdoes not have a user login script and if the container login script andthe 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 otherlogin scripts you have created.
For example, when Wilma logs in to company XYZ's network, the Marketingcontainer login script runs. (See Figure 1.)This login script maps the F: drive on Wilma's workstation to her home directoryon the network by including the following command:
MAP F:=SERV1\VOL1:\HOME\%LOGIN_NAME
The Marketing container login script does not include the NO_DEFAULTcommand or the EXIT command, and Wilma has not been assigned a profile loginscript. Because Wilma does not have a user login script, the default loginscript runs. However, this login script maps the first network drive onWilma's workstation to the SYS volume on her preferred server by includingthe following command:
MAP*1:=SYS:
On Wilma's workstation, the first network drive has been defined as theF: drive. (The first network drive is defined in the Network control panelor in the NET.CFG file for the Novell client software running on a user'sworkstation.) 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 directoryon the network, she cannot access the files in this directory.
CONCLUSION
With IntranetWare and NetWare 4, you can use four types of login scriptsto customize a user's workstation environment. However, you do need to avoidconflicts between login scripts and look for these conflicts when usersencounter problems with their workstation environment.
If you have any login script tips that you want to share, please sendan 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 broadcastmessage 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 andinstalled IntranetWare Client 2.11 for Windows 95 or higher, the upgradeprocess disabled NetWare User Tools, and Network Neighborhood now includesdrive-mapping and broadcast-message features. If users prefer to use NetWareUser Tools, you can reenable it by adding the following lines to the NETWARE.INIfile (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 runNetWare User Tools. In the NetWare User Tools window, users can click theMessage 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 technicalwriting.
* Originally published in Novell Connection Magazine
Disclaimer
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.