Planning the Directory Tree Structure

Novell Directory Services supports many different Directory tree structures. This flexibility ensures that your tree design is the most efficient for your particular network environment. To ensure that you build the most efficient structure, you should maintain four goals:

Provide intuitive and efficient access to network resources.
Provide secure access to shared resources that is easily maintained and monitored.
Develop a clear and concise blueprint for completing the implementation process.
Develop a flexible layout of the tree structure to ensure that future changes can be easily incorporated.

The basic design principles provided in this section should assist you in accomplishing these goals.

You should build your tree structure by actually drawing each layer of the Directory tree as you read the following discussions. You can use modeling or drawing software, or create diagrams of the structure on paper.

The most helpful documents for this procedure are organization and resource charts, location maps, and WAN topology charts.

Designing Upper Layers

Structuring the upper layers of the Directory tree is important to the general foundation of the tree and the tree performance. The upper layers are mostly affected by the WAN topology and speed of WAN links. This affects the kind of partitions and replicas you can use.

The upper layers include the following objects:

[Root] object
Organization objects
First layer of Organizational Unit objects

These layers build a solid framework for the bottom layers to be built upon. A few users and network resources need to be placed in the upper layers of the tree.

Naming Your Directory Tree

The highest object in the Directory tree is the [Root] object and is given the tree name. The [Root] object resides at the top of the tree and all other objects branch downward from it.

The [Root] object can be created only by the NetWare 4 installation program, which automatically places it at the top of the tree. Once the [Root] object is named, it can only be renamed by the DSMERGE utility.

A Directory tree name must be unique. Use a name that identifies your network and the organizational environment that the tree is designed for.

For example, a company that is named ACME Corporation and maintains a world-wide network might simply name their Directory tree ACME_CORP.

IMPORTANT: Multiple Directory trees can exist on the same network, but each tree needs a unique name.

Workstations use the tree name to connect to a server within the correct Directory tree. Network utilities reference the tree name by its unique name or by the [Root] object. Many utilities only refer to the object as [Root].

The Directory tree name or [Root] object can have trustees, and the rights granted to these trustees flow down the tree. One example is the User object ADMIN, which is created automatically during installation.

Determining the Directory Tree Foundation

The general foundation of the Directory tree is established through container objects. These objects represent the organizational and physical structure of the network.

Container objects hold (or contain) other Directory objects. Container objects provide a means of logically organizing all other objects in the Directory tree.

There are five kinds of containers:

Country (C)
The Country object designates the country where your network resides and organizes other objects within the country. This object is consistent with the X.500 specifications and is generally used by global directory providers as an entry point into their directory systems.

NOTE: Novell Directory Services more commonly uses Organizational Unit objects to represent geographical boundaries within an organization.

If you are not planning to use a third-party Directory provider, using the Country object might add an unnecessary level of complexity. If in the future the Directory tree needs the Country designator or needs the object added for merging with another tree, you can then add the Country object.

When used, the Country object must be placed directly below the [Root] object.

Figure 1
Example of a Tree Design with and without a Country Object
Locality (L)
The Locality object designates the location where this portion of your network resides and organizes other objects within the location.

The Country and Locality objects are characteristic of the X.500 specification, but are not commonly used within the Novell Directory Services design. This chapter does not discuss design information for using Country or Locality objects.

WARNING: Many NetWare 4 utilities do not recognize the Locality object. Use this object only when necessary for compliance with the X.500 specifications.

When used, the Locality object can be placed below the [Root] object, Country object, Organization object, or Organizational Unit object.
Licensed Product (LP)
Licensed Product objects are created automatically when you install a license certificate or create a metering certificate using NetWare Licensing ServicesTM technology.

When an NLS-enabled application is installed, it should add a Licensed Product container object to the Novell Directory database and a License Certificate leaf object to that container.

When used, the Licensing Product object can be placed below the [Root] object, Country object, Organization object, or Organizational Unit object.

For more information, see Chapter 10, Managing NetWare Licensing Services in Supervising the Network.
Organization (O)
An Organization object helps you organize other objects in the Directory tree. It also allows you to set defaults for User objects you create in the Organization container.

You can use an Organization object to designate a company, a division of a company, a university or college with various departments, or a department with several project teams.

Every Directory tree must contain at least one Organization object.

Organization objects must be placed directly below the [Root] object, unless a Country object or Locality object is used.
Organizational Unit (OU)
An Organizational Unit object helps you organize lower layer containers and other objects in the Directory tree. It also allows you to establish system level login scripts and to create a user template for User objects you create in the Organizational Unit container.

You can use an Organizational Unit object to designate a business unit within a company, a department within a division or university, or a project team within a department.

This object is optional. When used, Organizational Unit objects must be placed directly below an Organization, Organizational Unit, or a Locality object.

Establishing Tree Boundaries

Create container objects to establish a logical representation of the organizational and physical network infrastructure. This allows you to establish tree boundaries that facilitate efficient administration, scalability, security, and access to network resources.

The most helpful documents for this task are organization charts, location maps, and WAN topology charts.

Forming an Organization Layer

Novell Directory Services requires that at least one Organization object exist in the Directory tree. Organization objects can reside directly under the [Root] object or under a Country or Locality object.

Generally, a single Organization object is created directly under the [Root] object. It identifies an organization's name and provides a level of administration for the entire tree.

For example, a network administrator might set a specific set of file system rights for all files on network servers, or establish a system login script that is used for all users within an organization or department.

A single Organization object under the [Root] object also allows for easier merging of trees with other organizations.

If the Directory tree supports multiple organizations that maintain distinct administration strategies or act as separate business units, you may want to create multiple Organization objects.

For example, if the ACME Corporation functions as a single business unit and maintains the same general strategies for administration, access, and file system rights for the entire organization, create a single Organization object and name it ACME.

If the ACME Corporation functions as two distinct business units without common rights or access between the general business headquarters and the manufacturing headquarters in Europe, create two Organization objects named ACME and ACME_EURO.

The following figure illustrates how to use two Organizational object containers.

Figure 2
Directory Tree Design with Single and Multiple Organizational Object Containers

Use a name representative of the organization for naming the Organization object. Once you establish an Organization object name, consider registering the name with either the Internet or ANSI to enable future X.500 multiple tree and multiple name space operations.

When naming an Organization object, use short, concise names. Short names provide easy access to network resources and simple navigation throughout the tree. Creating short names also reduces the likelihood of mistyping names.

Forming Regional and Location Layers

The upper layers of the Directory tree are most affected by the geographical and physical structure of your network environment.

Because of this, you should structure the upper layers of your Directory tree to represent the major geographical locations in your organization and the network's hardware, communication links, and LAN/WAN topology. Doing this allows you to scale the Directory database according to the network's WAN structures.

The following table describes how to use Organizational Unit objects to represent a region-based and/or location-based structure of your organization's geographical network.

Type	Purpose
Location-based	Use the geographical locations within your organization's physical network infrastructure for naming location-based Organizational Unit objects. For example, if you have departments in different parts of a region, city, or campus, you could create SJC, SND, SFO containers, NORTH, SOUTH, EAST, WEST containers, or BUILD1, BUILD2, LIBRARY, HQ. Place the locational Organizational Unit objects directly under the Organization object layer. The locations should be geographical sites that have multiple departments or divisions included at each site. If the locations are small remote offices or field offices, you should place locational objects for those offices under an Organizational Unit object at a lower layer in the tree. See Designing Lower Layers for more information.
Region-based	Complex networks with multiple campus sites contained within a specific region should maintain a layer of region-based Organizational Unit objects above the location-based Organizational Unit objects. The network is easier to administer if the organization has regional offices that each manage a number of locations. For example, if you have divisions in three parts of a country and multiple departments in each part, you could create a WEST, MID, and EAST containers to contain individual groups of location-based containers, such as SJC, SND, SFO. Designing your tree according to the geographical structures of your organization also provides a more intuitive interface to the Directory tree. Users at a specific location can identify their location (or context) in the Directory tree by the location, or city that they work in. Organizing upper layers of the tree by the geographical structures in your organization also makes it easier for users to remember where their commonly-accessed network resources are. It also provides better organization for storing information and applications in your environment.

Type

Purpose

Location-based

Use the geographical locations within your organization's physical network infrastructure for naming location-based Organizational Unit objects.

For example, if you have departments in different parts of a region, city, or campus, you could create SJC, SND, SFO containers, NORTH, SOUTH, EAST, WEST containers, or BUILD1, BUILD2, LIBRARY, HQ.

Place the locational Organizational Unit objects directly under the Organization object layer.

The locations should be geographical sites that have multiple departments or divisions included at each site. If the locations are small remote offices or field offices, you should place locational objects for those offices under an Organizational Unit object at a lower layer in the tree. See Designing Lower Layers for more information.

Region-based

Complex networks with multiple campus sites contained within a specific region should maintain a layer of region-based Organizational Unit objects above the location-based Organizational Unit objects. The network is easier to administer if the organization has regional offices that each manage a number of locations.

For example, if you have divisions in three parts of a country and multiple departments in each part, you could create a WEST, MID, and EAST containers to contain individual groups of location-based containers, such as SJC, SND, SFO.

Designing your tree according to the geographical structures of your organization also provides a more intuitive interface to the Directory tree. Users at a specific location can identify their location (or context) in the Directory tree by the location, or city that they work in.

Organizing upper layers of the tree by the geographical structures in your organization also makes it easier for users to remember where their commonly-accessed network resources are.

It also provides better organization for storing information and applications in your environment.

NOTE: If you are designing a tree for a single site or a single or multiple campus environment with fast WAN links (T1 or better) and have no future plans for expanding to other locations, you won't have issues concerning the geographical or physical network structure. Go to Designing Lower Layers to continue.

The following figures illustrate how to design a Directory tree according to your organization's geographical structure.

Figure 3
Physical Map of an Organizational Structure

Figure 4
Example of Region-based Tree Design

Novell Directory Services is designed to operate in a fairly stable networking environment. The Directory tree design should account for any intermittent links, on-demand links, or WAN links with minimal available bandwidth that exist in the network.

When designing for particular LAN/WAN topologies, consider the following factors:

Bandwidth
Speed
Cost
Regulations

Designing Lower Layers

The lower tree layers provide a high level of flexibility to support any layout that suits your environment needs.

The lower layers include the following objects:

Second and subsequent layers of Organizational Unit objects
Leaf objects

These layers are built upon the foundation established in the upper layers. They provide the logical divisions of network resources and lower level organizational structures that exist in your organization. Most objects in your tree will be in these layers.

The most helpful documents for this task are organization and resource charts.

Determining the Directory Tree Framework

The general framework of the Directory tree is established through the Organizational Unit objects that represent the logical divisions, departments, and workgroups in your organization.

Organizational Unit objects help you to organize lower layer containers and other objects in the Directory tree. They also allow you to establish system-level login scripts and to create a template for User objects.

Lower layers should be designed for naming and organizing network resources and not for creating consistent subtrees or container structures within your tree.

The following two figures illustrate how container objects can be used to design the lower layers of your Directory tree structure.

Figure 5
Lower Layer of a Simple Directory Tree

Figure 6
Lower Layer of a Complex Directory Tree

Forming Containers Based on Common Access

The most important consideration when structuring the lower layers is to create containers for network resources that have common access needs to other Directory objects. This allows you to make single trustee assignments or administer a single system login script for many users.

Use an organizational chart to provide the logical structure for container names.

Individuals in your organization chart should not be included in the tree as Organizational Unit objects. Container objects should also not be created as placeholders. Each container should only be created for existing functional groups and resources within the organization.

Use Organizational Unit objects to represent functional groups as container objects. Place these containers directly under the location-based Organizational Unit objects or under the Organization object depending on how many geographical locations exist in your organization.

See Creating an Accessibility Plan for more information.

Forming Containers Based on Workflow

Identify the workflow of your organization to determine possible groupings of individuals and services based on tasks rather than departmental lines.

If your organization maintains long-term projects or is highly process-oriented, you might create container objects.

Use Organizational Unit objects to represent the projects or products as container objects. Place these containers under Organizational Unit objects in a division or department. These types of containers are usually created at the lowest layers within the tree.

Use a project resource chart relying on project names to provide the logical structure for container names.

Individuals in your project chart should not be included in the tree as Organizational Unit objects. Container objects should also not be created for short-term projects or as place holders for future projects. Each container should only be created for project teams or production groups that access and use similar resources in the organization.

Forming Containers Based on Management Structures

The administrative model used in your organization can affect the design of the lower tree layers. With NetWare 4^TM software, you can centralize network administration so that a single person or small group of people control the entire network.

You can also distribute administration so that many network supervisors throughout the organization control their own portion of the Directory tree.

The following table describes the three types of administrative models that should be considered when designing the lower layers of the tree.

Administrative Model	Action
Centralized	To provide for greater central administration of the network, design the tree with more layers of hierarchy for faster browsing.
Decentralized	To provide for better local administration of the network, design the tree with separate container objects for each administrative area in the tree.
Mixed	To provide for mixed administration of the network, use a hybrid of both central and local administration. You should ensure, however, that lower layer containers are managed by local administrators and upper layers are administered at central sites.

Forming Containers Based on Service Groups

Use a service-oriented approach such that users of similar services are grouped together across departments or other boundaries.

Incorporating Specific Design Elements

Some specific design elements may exist for your network that affect the framework used in the lower layers of the Directory tree. These elements are:

Database scalability (partitioning and replication)
Number of objects
Network infrastructure
Tree depth and name length

Database Partitioning and Replication

To adequately scale the Directory database and distribute portions of it across multiple servers, you should ensure that at least one Organizational Unit object exists for each portion of the tree that you want to partition.

Number of Objects

Create separate containers if the number of objects for a given container exceeds 5,000 objects. This provides for easier administration and scalability.

Network Infrastructure

Create a container for remote sites with slow links that belong to a particular division or department. For example, objects that represent resources belonging to a field sales office should be separated into their own container.

Tree Depth and Name Length

An appropriate depth for your environment enables easier access and management.

The Directory tree should maintain a depth between four to eight layers. As the complexity of your environment increases, either in numbers of objects or in the number of locations under single management, the tree depth will usually increase to accommodate those conditions.

You should also ensure that the accumulated name length from the lowest layer to the top of the tree ([Root] object) does not exceed 256 characters.

Limitation of DOS command line utilities impose a maximum name length of 255 characters. When shorter Organizational Unit names are used, a deeper tree may be designed. However, the greater the depth of the tree, the more complex access to network resources may be.

When objects are created, they are checked to ensure that the maximum name length of the object isn't exceeded. However, it is possible to later rename an object and cause the name to exceed 255 characters.

Reviewing the Directory Tree Structure

As you draw (model) the Directory tree structure, also evaluate the tree design. Each member of the project team should have the opportunity to review the tree structure before continuing to the next procedure for placing network resources in containers.

If you are upgrading from a NetWare 2 or NetWare 3^TM, you can use the Novell Directory Services migration utility to assist you in modeling your bindery data for migrating to the NetWare 4 Directory database.