Creating Leaf Objects

Leaf objects represent network resources, such as users, computers, printers, and lists. They do not contain any other objects.

You create leaf objects within a container object. Figure 2-2 lists the leaf objects you can create. (The icons represent the objects as they appear in NetWare Administrator.)

Figure 2-2 Leaf Objects You Can Create




	NOTE: The first three leaf objects in the figure - Message Routing Group, External Entity, and Distribution List - are NetWare MHS Services objects. They appear in NetWare Administrator only if you have installed NetWare MHS Services on your NetWare server.

How to Use Leaf Objects

Table 2-4 describes in alphabetical order each leaf object you can create and when to use it.

Table 2-4 Leaf Objects You Can Create

Leaf object	Description	When to use
Alias	Points to another object in the Directory tree and makes it appear as if that object actually exists in the Directory tree where the alias is. Although an object appears both where it was actually created and where an alias referring to it was created, only one copy of the object really exists. If you delete or rename an alias, the object it is pointing to is not affected.	Use this object to allow easier access to an object that is in another context. For example, you can use an Alias to represent a resource, such as a special printer, that most users in the tree need to access. Also, when you move or rename a container object in a Directory tree, you have the option of creating an alias in place of the moved or renamed object. If you select this option, NetWare Administrator automatically creates the alias for you and assigns it the same name as the original object. Creating an alias in place of a moved or renamed container object allows users to continue logging in to the network and see the container objects (and the objects it contains) in its original Directory location.
Computer	Represents a nonserver computer on the network, such as a workstation or a router.	Use this object to store information about a nonserver computer, such as its network address, its serial number, or the person to whom the computer is assigned. This object has no effect on the operation of the network; it only stores information about the computer.
Directory Map	Represents a particular directory in the file system. Directory Map objects can be especially useful in login scripts by pointing to directories that contain applications or other frequently used files. For example, if you have a directory that contains DOS 5.0, you will probably map a search drive to that directory in the login scripts you create. Later, if you upgrade to DOS 6.0 and rename the directory, you would have to change the mapping in every login script where that search mapping appears. With a Directory Map object, you change only the information in that one object.	Use this object to avoid making changes to many login scripts when the location of applications changes. For more information on Directory Map objects, see "Loading Operating Systems and Applications onto the Network" in Chapter 3.
Distribution List	Represents a list of mail recipients.	Use this object to simplify sending mail. For example, you could create a Distribution List object called Recreation Committee. Anyone wanting to send a message to all the members of the Recreation Committee can simply address the message to Recreation Committee, rather to each member.
External Entity	Represents a non-native NDS object that is imported into NDS or registered in NDS. NetWare MHS Services use external entity objects to represent users from non-NDS directories to provide an integrated address book for sending mail.	If your messaging environment contains non-MHS servers, such as SMTP hosts, SNADS nodes, or X.400 MTAs, you might choose to add users and lists at these servers to your NetWare database as External Entities. Adding these objects to the database as external entities adds them to the address books of your messaging applications. When addressing messages, local users can choose non- MHS users and lists from a directory list.
Group	Assigns a name to a group of User objects that can be located anywhere in the Directory tree.	Create a Group object when you have many User objects that need the same trustee assignments. Rather than making many trustee assignments, you make just one trustee assignment to a Group object for all users who belong to the group.
Message Routing Group	Represents a group of messaging servers that can transfer messages directly with each other.	Create a Message Routing Group when you have two or more messaging servers that need to communicate with each other.
NetWare Server	Represents a server running NetWare on your network. Stores information about the server in the NetWare Server object's properties, such as the server's address, the physical location of the server, and what services it provides. The NetWare Server object affects the network in that it is referred to by several other objects.	Use the NetWare Server object to associate the physical server on the network with the Directory tree. Without this object, users cannot access file systems that are on that server's volumes. If you have a non-NetWare 4.1 server, you must create this object to be able to access non-NetWare 4.1 volumes. When you create a NetWare Server object for a non-NetWare 4.1 server, the non-NetWare 4.1 server must be running.
Organizational Role	Defines a position or role within an organization.	Create an Organizational Role object so that you can assign rights to a particular position rather than the person who occupies that position. The occupant may change frequently, but the responsibilities of that position do not. You can assign any user to be an occupant of the Organizational Role object because every occupant receives the same rights that you granted to the Organizational Role object.
Print Queue	Represents a print queue on the network.	You must create a Print Queue object for every print queue on the network. This object cannot be created with NETADMIN. See Print Services for more information.
Print Server	Represents a network print server.	You must create a Print Server object for every print server on the network. This object cannot be created with NETADMIN. See Print Services for more information.
Printer	Represents a physical printing device on the network.	You must create a Printer object for every printer on the network. This object cannot be created with NETADMIN. See Print Services for more information.
Profile	Contains a profile script (login script). When the Profile object is listed as a User object's property, the Profile Object's login script is executed when that User object logs in. The Profile login script executes after the system login script and before the user login script.	Create a Profile object for a set of users who need to share common login script commands but who are not located in the same container in the Directory tree, or who are a subset of users in the same container.
User	Represents a person who uses your network. In the User object properties, you can set login restrictions, intruder detection limits, password and password restrictions, security equivalences, etc.	You must create a User object for every user who needs to log in to the network. When you create a User object, you can create a home directory for that user. When you create User objects, you can also choose to apply a user template to the user that provides default property values. For users who have NetWare 4.1 workstations, you can create the User objects anywhere in the Directory tree, but the users must know their context in order to log in. You should create User objects in the container where the users will typically log in. For users who have non-NetWare 4.1 workstations, you must create the User objects in the container at which the bindery services context is set for the server that they need to log in to. (Bindery services is set by default for every NetWare 4.1 server that is installed.) Non-NetWare 4.1 users do not need to know their context because they log in to the server rather than to the Directory tree.
Volume	Represents a physical volume on the network. In the Volume object's properties, you can enter identification information, such as the host server, volume location, etc. You can also set restrictions for use of the volume, such as space limits for users.	You should create a Volume object for every physical volume on the network. During installation of NetWare® 4.1/ 9000 NetWare Services on a server, Volume objects are created for every physical volume on that server. When you create a volume, you are prompted for the server name and the volume name on the server. That information is placed in the Volume object's properties. You can use the Volume object to display the directories and files on that volume.

Naming Leaf Objects

The object naming rules described in the next section apply to most leaf objects. Special rules applying to NetWare Server objects and objects viewed through bindery services are described in separate sections. For rules about naming container objects, see "Naming Container Objects" in this chapter.

Object Naming Rules

Remember these rules when naming an object:

The name must be unique in the branch (container) of the Directory tree where the object is located.
The object name can be up to 64 characters in length.
You can use any special characters. But if the object needs to be accessed from a client running a version of NetWare earlier than NetWare 4.1, you should avoid using special characters (see the next section).
You can enter object names in either uppercase or lowercase. Object names are displayed with uppercase and lowercase letters as they were first entered, but they are not case sensitive. Therefore, "ManagerProfile" and "MANAGERPROFILE" are considered to be identical names.

You can use both spaces and underscores, but they are both considered spaces. Therefore, "Manager_Profile" and "Manager Profile" are considered to be identical names.

If you use a space in a name, you must place quotation marks around that text string whenever you use a command line utility that includes that text string.




	NOTE: If you anticipate managing objects created from different code pages, you must limit object names and properties to those characters common to all the applicable code tables. Nondisplayable Unicode characters for your code page are represented by an ASCII 3 character (a "heart" symbol). For more information, see "Unicode" in Concepts.

Object Name Restrictions for Bindery Services

When you create objects to be accessed from a client running a version of NetWare earlier than NetWare 4, the names of the objects must follow bindery naming rules or else the pre-NetWare 4 client does not recognize them. Object names in bindery services are interpreted as the following:

Spaces in object names are replaced by underscores.
Object names longer than 47 characters are cut off after the 47th character.

You cannot use the following characters in an object name that must be accessed from a client running a version of NetWare earlier than NetWare 4:

/ slash

\ backslash

: colon

, comma

* asterisk

? question mark

Naming Restrictions for NetWare Server Objects

The first NetWare Server object for a NetWare 4.1 server must be created with Directory Services Install. The object is given the same name as the physical server. Rules for naming physical servers appear in Help of Directory Services Install.

If you create a NetWare Server object for a non-NetWare 4.1 server, you must use the physical server name as well, because NetWare Directory Services must search for the server on the network to verify its existence.

For example, if you create a Server object for a NetWare 3™ server whose physical name on the network is SURFBOY, you must name the Server object SURFBOY.

Because of these restrictions, you can never rename a NetWare Server object, even if you have the Supervisor object right to it. For more information on NetWare Server objects, see "Object" in Concepts.

Creating Searchable Leaf Objects

When you create an object, you enter various types of information about that object into its properties. An object's properties can include a telephone number, a description, an address, etc.

Many object properties are optional; you are not required to enter information about such properties to create the object. However, information in objects' properties can help you track and manage those objects.

After you have created objects, you can use NetWare Administrator, NETADMIN, or NLIST to search for and list these objects. You can also search for the values contained in the objects' properties.

If you enter data into the properties in a consistent format, it is easier to search the Directory database for different types of information when you need them.

For example, you may want to search for all User objects at a certain location, such as building M1. You cannot easily list all objects located in building M1 if you have entered "Bldg. M1," "BLDG M1," and "M1" as values in the Location property of multiple User objects.

Standardizing the value for the Location property for all User objects at the site (such as M1, M2, and M3) makes it possible to search for objects located in each building.