Migrating to Netware 4.1

- 11 -

Setting Up Login Scripts

Login Script Types
- System Login Script
- Profile Login Script
- User Login Script
- Default Login Script
- The NO_DEFAULT Directive
- Login Script Execution Order
- Upgrade Considerations for Login Scripts
- Rights to Execute Login Script Property Value

Many of the NetWare 3.x login script commands can be used with NetWare 4.x. NetWare 4.x includes a few additional login script commands, but the biggest difference is in the area of login script organization. In NetWare 3.x, there were three types of login scripts: system, user, and default login scripts. NetWare 4.x has an additional login script type called the profile login script. The scope of the system login script has also changed. In NetWare 3.x, the system login script applied to all user accounts defined on the file server. In NetWare 4.x, the system login script applies to user accounts for the container on which it is defined.

This chapter shows you what you need to know to make use of NetWare 4.x's login script features. I assume you have some experience with login scripts in NetWare 3.x. If not, refer to NetWare Training Guide: NetWare 4 Administration, also by New Riders Publishing.

Login Script Types

NetWare 4.x supports four types of login scripts. These are

System login script
Profile login script
User login script
Default login script

The system login script is a property of the Organization and Organizational Unit container objects. The profile login script is a property of the profile leaf object. The user login script is a property of the User object. The default login script does not exist as an object or a property; it is contained in the LOGIN.EXE utility that is used for logging in to the network. Because login scripts are properties of objects, NDS tools such as NETADMIN or NetWare Administrator can be used for creating and modifying login scripts.

Each of these different login script types are discussed in the following sections.

System Login Script

The system login script is a property of the Organization and Organizational Unit container objects, and its scope is the User objects defined in that container. This means that system login scripts are a convenient way of specifying the commands that should be executed for all users belonging to an organization or department (organizational unit) within the organization.

The system login script is executed for only the immediate users in that container. In figure 11.1, the system login script for organization O=SCS applies only to the users Admin, KSS, and Dei that are defined in that container. The system login script does not apply to users Lisa, Janice, or Bill in container OU=ENG.O=SCS. The container OU=ENG has its own system login script, and this applies to users Lisa, Janice, and Bill. The container OU=SALES.O=SCS does not have a system login script. This means that for users Nina, John, and Dorsch there is no system login script. If a container does not have a system login script, it does not inherit the system login script from a parent container.

NOTE: Inheritance of system login script from a parent container would unnecessarily complicate the network computing environment. For instance, if the system login script were removed from a parent container, then inheritance means that the user may execute the login script of the parent's parent container. The login script execution of a parent container might not make sense because the login script usually makes references to network resources that are available to users in the container, and these resources might not be available to user objects several levels down on the directory information tree.

Figure 11.1 The scope of the system login script.

The system login script is the first type of login script that is executed and can be used to set up the general environment for all users in that container.

To create a system login script, you must highlight the container object using NETADMIN or NetWare Administrator and select its Login Script property for modification.

Profile Login Script

A profile login script is a property of the Profile object. The Profile object is a leaf object, whose sole purpose is to contain the profile login script (see fig. 11.2). If a group of users has common needs, they fit a certain profile. In this case a Profile object can be assigned to each of the users.

Every User object has a profile login script property (as well as a user login script property). The profile login script property for a user can contain the name of a Profile object. If the profile login property for a User object is set to a Profile object, the profile login script (property of the Profile object) is executed every time that user logs in. If the profile login property for a User object is not set, no profile login script is executed when that User object is logged in.

NOTE: The profile login script is set by assigning a Profile object to the User object's profile login property.

Figure 11.2 Profile login script.

The profile login script is executed after the system login script, and a User object can have only one profile login script.

The profile login script seems to be similar to the system login script. What, then, is its purpose? The system login script applies only to User objects that are in the immediate container. There may be situations when users belonging to different containers have a common need for setting up their user environment. The profile login script property for users can be set to the same Profile object, even if the User objects are defined in different containers. This makes it possible for users in different containers to have a common login script.

TIP: Use system login scripts to meet the common needs of users in a container. For most organizational structures, this should be enough. Use the Profile object only if users in different departments, or organizations, need to have a common login script. Using profile login scripts can complicate future maintenance if the login require-ments change. Potentially, you might have to change the profile login script property of every User object. Use the NLIST command to search for users who have the same Profile object value for their profile login script property.

NOTE: The profile login script is executed after the system login script but before the user login script.

NOTE: A User object can have only one profile login script.

User Login Script

Every User object has a login script property (see fig. 11.3). The value for the login script property can be a sequence of login script commands. The same type of login script commands that are used for the system and profile login script can be used for user login scripts. The user login script is set by entering login script commands for the User object's user login property.

Figure 11.3 User login script.

The user login script is executed after the profile login script (if any).

The user login script can be used to customize a user's login environment. The other login scripts (system and profile) are used to share common login script commands with other users. A user might have special needs that are not addressed by these "group" login scripts. In that case, use the user login script to further customize the user's environment.

Default Login Script

The default login scripts are unlike all the other login scripts in the sense that, although the other login scripts can be modified, the default login script cannot be modified. The default login script is fixed, and can be considered to be "contained" in the login program, LOGIN.EXE. It is meant to provide a minimum user environment in case a user logs in and does not have a user login script. This is certainly true the first time the user Admin logs in to a newly installed network. A newly installed network does not have any system, profile, or user login script set up. The Admin user can at least perform some basic administration without having to create drive mappings.

After a user login script is created for that user, the default login script will not execute for that user. In some situations, all of the login script needs of a user might be met by the system login script or the profile login script. In this case, there is no need to have a user login script. However, because the user login script has not been set, the default login script will execute, in addition to any system and profile login scripts. One of the default actions the default login script performs is to set up a search drive mapping to SYS:PUBLIC. If the system or profile login scripts already map a search drive to SYS:PUBLIC, a second search drive mapping to SYS:PUBLIC will be created unless the user login script property is set, or the NO_DEFAULT login directive exists in the system or profile login script.

The NO_DEFAULT Directive

The NO_DEFAULT directive in the system or profile login script can explicitly disable the execution of the default login script (see fig. 11.4). This is useful if you want to override the default mappings that are created when the user login script property is not set but do not want to set the user login property because the login scripts of the system and/or profile login script are sufficient to set up the required user environment.

Figure 11.4 The NO_DEFAULT login script.

Login Script Execution Order

The order of execution for the login script types is illustrated in figure 11.5 and also listed here. These steps are executed when the user logs in to a NetWare 4.x network.

1. If a user's container has the system login script property set, the system login script is executed for that user.

2. If a user's profile login script property is set to a profile object, the profile login script for that profile object is executed for that user.

3. If a user's login script property is set, the user login script for that user object is executed.

4. If a user's login script property is not set, the default is executed unless the NO_DEFAULT login script command has been included in the system or profile login script.

Some examples help illustrate the preceding rules. Figure 11.6 shows an example of the NDS tree for organization O=TEC that has a system login script.

Figure 11.5 The login script order.

Figure 11.6 An example of login script execution.

Under O=TEC, there are two Organizational Unit objects. One of the Organizational Unit objects (OU=ENG) has a system login script, although the other (OU=EXP) does not have a system login script. The users Admin, KSS, and Bill have a user login script, but user Charles does not have a login script. The user KSS also has a profile login script property set to the profile object CN=Profile1.OU=ENG.O=TEC. The order of execution of login scripts for the different users follows the figures.

User KSS:

User KSS's container has a system login script. So the system login script for OU=ENG is executed first. User KSS also has a profile login script. This is executed next. Finally, a check is made to see whether user KSS has a user login script. Because user KSS has a user login script, this is executed next. The order of login script executions for user KSS is:

System login script for OU=ENG
Profile login script for profile object PROFILE1.ENG.TEC
User login script for KSS

User Bill:

User Bill's container has a system login script. The system login script for OU=ENG is executed first. User Bill does not have a profile login script. A check is made to see whether user Bill has a user login script. Because user Bill has a user login script, this is executed next. The order of login script executions for user Bill is:

System login script for OU=ENG
User login script for Bill

User Admin:

User Admin's container has a system login script. The system login script for O=TEC is executed first. User Admin does not have a profile login script. A check is made to see whether user Admin has a user login script. Because user Admin has a user login script, this is executed next. The order of login script executions for user Admin is:

System login script for O=TEC
User login script for Admin

User Charles:

User Charles' container OU=EXP does not have a system login script. So no system login script is executed. User Charles does not have a profile login script. A check is made to see whether user Charles has a user login script. Because user Charles does not have a user login script, the default login script is executed next.

Upgrade Considerations for Login Scripts

When upgrading from an earlier NetWare version to NetWare 4.x, the first system login script encountered for a file server that is placed in a container object becomes the system login script property of that container object. Any subsequent system login scripts from file servers that are placed in the same container are ignored. It is, therefore, important to upgrade the server that contains the most up-to-date version of the system login script first.

Even though the earlier NetWare login scripts are compatible with NetWare 4.x, you should review the upgraded login scripts to see if you can take advantage of the new NetWare 4.x features. If the directories on which you want to map network drives are on volume objects that are in a different context than that where the users are defined, you will have to modify the login script MAP commands to refer to the NDS name of Volume objects.

Rights to Execute Login Script Property Value

The login script is a property of the NDS object, the system login script is a property of the organization or organizational unit container, the profile login script is a property of the Profile object, and the user login script is a property of the User object. For a User object to execute the login scripts when the User object is logged in, that User object must have certain rights to that login script property.

Containers are granted the Read property right to their login script. The User object in the container must have the Browse right to the container object and the Read property right to the login script to execute the system login script. The Browse right to the container is usually granted by inheritance. For example, it is typical in most NDS trees to make [public] a trustee of [Root] with the Browse right. Users in a container, then, inherit the Browse right.

NOTE: The User object in the container must have the Browse right to the container object and the Read property right to the login script in order to execute the system login script.

NOTE: Containers are granted the Read property right to their login script (system login script).

Profile login scripts are assigned by setting a user's profile login script property to the name of the Profile object. The user needs to be made a trustee of the Profile object. When a user is made a trustee of the Profile object, the following rights are by default assigned to the user:

1. Browse object right to the Profile object.

2. Read and Compare property rights to the All Properties of the Profile object.

Because of the All Properties Read and Compare rights, the user inherits these rights for the profile login script property also.

Users are by default assigned Read and Write property rights to their user login script property. The Write property right enables a user to modify his or her own login scripts. In some network environments, it might not be desirable for users to modify their login scripts. In this case, the Write property right to the login script must be removed.

Most of the NetWare 4.x commands are the same as NetWare 3.x. The new login script commands are listed in table 11.1.

TABLE 11.1 New Login Script Commands

Login Command	Description
ATTACH	Attach to bindery-based servers. Can also attach to NetWare 4.x servers in bindery emulation mode.
CLS	Clears screen. This had to be done by the #COMMAND /C CLS in earlier NetWare versions.
CONTEXT newcontext	Can be used to change the user's context from login script.
INCLUDE NDSObjectName	Can be used to invoke login scripts that are properties of other NDS objects. The traditional INCLUDE filename used in earlier NetWare 3.x also works in NetWare 4.x.
LASTLOGINTIME	Used to display the last time the user logged in. Used for informational purposes.
MAP CHANGE or MAP C	Change drive from ordinary network drive to search drive and vice versa.
MAP NP	No Prompt. Override existing mapping without prompting user to verify the operation.
MAP P	Map drive pointer to physical volume rather than the volume object.
NO_SWAP	NO_SWAP prevents LOGIN.EXE from being swapped out to high memory.
SWAP	SWAP (default) can result in LOGIN.EXE being swapped out if there is insufficient memory to run LOGIN.EXE, especially when executing # commands.
PROFILE profobject	Used to override the profile script assigned to a user or specified at the command line, and cause the user to execute a PROFILE script profobject.
SET_TIME [ON\|OFF]	SET_TIME ON is used to synchronize workstation time to the server that it is first attached to. This is the default behavior. SET_TIME OFF disables this default behavior.
NO_DEFAULT	When used in system login script or profile login script, it can disable the default login script from running.

Migrating to Netware 4.1 -- Ch 11 -- Setting Up Login Scripts