Designing the NDS tree is the most important procedure in the design and implementation of a network. The design consists of the following tasks:

Using standard names such as object names makes your network more intuitive to both users and administrators. Written standards can also specify how administrators set other property values, such as telephone numbers and addresses.

Searching and browsing the directory rely greatly on the consistency of naming or property values.

Naming Conventions

Objects

• The name must be unique in the container. For example, Debra Jones and Daniel Jones cannot both be named DJONES if they are in the same container.
• Special characters are allowed. However, plus signs (+), equals signs (=), and periods (.) must be preceded by a backslash (\) if used. Additional naming conventions apply to Server and Country objects, as well as to bindery services and multilingual environments.
• Uppercase and lowercase letters, as well as underscores and spaces, are displayed as you first entered them, but they aren't distinguished. For example, Manager_Profile and MANAGER PROFILE are considered identical.
• If you use spaces, you must enclose the name in quotes when entering it on the command line or in login scripts.

• Server objects are automatically created when you install new servers.
• You can create additional Server objects for existing NetWare and NT servers and for NDS servers in other trees, but they are all treated as bindery objects.
• When creating a Server object, the name must match the physical server name, which:
  • Is unique in the entire network
  • Is from 2 to 47 characters long
  • Contains only letters A-Z, numbers 0-9, hyphens, periods, and underscores
  • Doesn't use a period as the first character

• Once named, the Server object cannot be renamed in ConsoleOne^TM. If you rename it at the server, the new name automatically appears in ConsoleOne.

Country objects should follow the standard two-letter ISO country code.

Bindery Objects

If the object is accessed from NetWare^® 2 or NetWare 3 through bindery services, the following restrictions apply:

• Spaces in the name are replaced with underscores
• Names are truncated to 47 characters
• The following characters are not allowed: slash (/), backslash (\), colon (:), comma (,), asterisk (*), and question mark (?)

Bindery emulation is not supported on Linux*, Solaris*, or Tru64 UNIX* platforms.

Multilingual Considerations

If you have workstations running in different languages, you might want to limit object names to characters that are viewable on all the workstations. For example, a name entered in Japanese cannot contain characters that aren't viewable in Western languages.

The Tree name should always be specified in English.

Sample Standards Document

The following is a sample document containing standards for some of the most frequently used properties. You only need to have standards for those properties you use. Distribute the standards document to all administrators responsible for creating or modifying objects.

Table 12.

Designing the Upper Layers of the Tree

You should carefully design the upper layers of the tree because changes to the upper layers affect the rest of the tree, especially if your organization has WAN links. You want to design the top of the tree so that few changes will be necessary.

Use the following NDS design rules to create your NDS tree:

• Use a pyramid design.
• Use one NDS tree with a unique name.
• Create a single Organization object.
• Create first-level Organizational Units that represent the physical network infrastructure.

Figure 1

Using a Pyramid Design

With a pyramid-designed NDS, managing, initiating changes to large groups, and creating logical partitions are easier.

The alternative to the pyramid design is a flat tree that places all objects in the top layers of the tree. NDS can support a flat tree design; however, a flat tree design can be more difficult to manage and partition.

Using One NDS Tree with a Unique Name

A single tree works best for most organizations. By default, one tree is created. With one tree you have a single user identity on the network, simpler administration of security, and single point of management.

This recommendation for a single tree for business use does not preclude additional trees for testing and development.

Some organizations, however, might need multiple trees because of legal, political, or corporate issues. For example, an organization consisting of several autonomous organizations might need to create several trees. If your organization needs multiple trees, consider using DirXML to simplify management. For more information on DirXML, refer to DirXML Administration Guide.

When you name the tree, use a unique name that will not conflict with other tree names. Use a name that is short and descriptive, such as EDL-TREE.

If two trees have the same name and are located on the same network, you might encounter the following problems:

• Updates going to the wrong tree
• Resources disappearing
• Rights disappearing
• Corruption

You can change the tree name using the DSMERGE utility, but do so with caution. A tree name change impacts the network because you need to reconfigure the clients to use the new tree name.

Creating a Single Organization Object

Generally, an NDS tree should have one Organization object. By default, a single Organization object is created and named after your company. This allows you to configure changes that apply to the whole company from a single location in the tree.

For example, you can use ZENworks^TM to create a Workstation Import Policy object in the Organization object. In this policy, which affects the whole organization, you define how Workstation objects are named when created in NDS.

In the Organization container, the following objects are created:

• Admin

• Server

• Volume

  Networks with only a Windows* NT* server running NDS have no Volume objects.

You might want to create multiple Organization objects if your company has the following needs:

• It comprises multiple companies that do not share the same network.
• It needs to represent separate business units or organizations.
• It has a policy or other internal guidelines that dictate that organizations remain separate.

First-level Organizational Unit design is important because it affects the partitioning and efficiency of NDS.

For networks that span more than one building or location using either a LAN or a WAN, the first-level Organizational Unit object design should be based on location. This allows you to partition NDS in a way that keeps all objects in a partition at one location. It also provides a natural place to make security and administrator assignments for each location.

Designing the Lower Layers of the Tree

You should design the lower layers of the tree based on the organization of network resources. You have more freedom in designing the lower layers of an NDS tree than the upper layers because lower-layer design only affects objects at the same location.

Determining Container, Tree, and Database Size

The number of lower-level container objects you create depends on the total number of objects in your tree and your disk space and disk I/O speed limitations. NDS eDirectory^TM has been tested with over 1 billion objects in a single NDS tree, so the only real limitations are disk space, disk I/O speed, and RAM to maintain performance. Keep in mind the impact of replication on a large tree.

A typical object in NDS eDirectory is 3 to 5 KB in size. Using this object size, you can quickly calculate disk space requirements for the number of objects you have or need. Keep in mind that the object size will grow depending upon how many attributes are completed with data and what the data is. If objects will hold binary large object (BLOB) data such as pictures, sounds, or biometrics, the object size will subsequently grow.

The larger the partitions, the slower the replication cycles. If you are using products that require the use of NDS, such as ZENworks and DNS/DHCP services, the NDS objects created by these products will affect the size of the containers they are located in. You might consider placing objects that are for administration purposes only, such as DNS/DHCP, in their own partition so user access is not affected with slower replication. Also, managing partitions and replicas will be easier.

If you are interested, you can easily determine the size of your NDS eDirectory database or the Directory Information Base (DIB) Set.

In general, create containers for objects that have access needs in common with other NDS objects. This lets you service many users with one trustee assignment or login script. You can create containers specifically to make container login scripts more effective, or you can place two departments in one container to make login script maintenance more feasible.

Keep users close to the resources they need to limit traffic over the network. For example, people who work in the same department generally work near each other. They usually need access to the same file system, and they print to the same printers.

Exceptions to general workgroup boundaries are not hard to manage. If two workgroups use a common printer, for instance, you can create an Alias object to the printer in one of the workgroups. You can create Group objects to manage some User objects within a workgroup or User objects across multiple workgroups. You can create Profile objects for subsets of users with unique login script requirements.