The Novell Directory Services (NDS) database is one of the most critical pieces of the NetWare network puzzle. A good design makes the network more efficient, secure, scalable, and fault-tolerant.
Because there have been entire books written on how to design an NDS structure, we’ll present only a high-level overview here. Nevertheless, these guidelines should help lead you down the path toward a good NDS design.
A logical NDS structure provides many benefits. Users have an efficient and predictable structure that allows them to easily locate and access network resources. Network administrators can easily name, locate, manage, and secure network resources. Network performance increases, and the NDS database is more fault-tolerant.
Just as each organization is different, each NDS design will differ. One company may have five locations with a different department based in each location. Another company may have one location with five different departments. Still another company might have 10 locations with the same seven departments at each location.
Remember the pyramid
Your NDS design must be based on both the organizational structure and network layout of your company. Generally, the NDS structure should resemble a pyramid. The top will have few objects, and the lower layers will have more objects.
Creating a naming standards document is an important first step, although it's often overlooked. This document provides you with consistent naming conventions for the entire NDS structure and for all the network resources. Although it may seem like a tedious and boring task, the naming standards document will prove to be invaluable over time.
You’re in the right place. Check out the AdminRepublic article "Three easy steps to creating an NDS tree naming standards document."
The upper layers
You start the design process by creating the upper layers of the NDS structure. The [ROOT] object will be at the top of the tree and should be followed by one organization object. Even if the company is very small, the organization object will provide flexibility when the company grows or if you have to merge NDS trees.
Under the organization object, you should place a few organizational unit objects. If the company has a single site, you may have just a few organizational units, with each representing workgroups or departments. If you’re working with multiple locations in different countries or geographic regions, you can use separate organizational units to represent each location.
Try to keep things simple. Too many organizational objects will only cause confusion.
The lower layers
After you’ve completed the upper-layer design, focus on the lower layers of the tree. These layers, if needed, will represent various things depending on how you've structured the upper layers. For example, the organizational units can represent physical locations, departments, workgroups, or just about anything else. Again, keep things simple and avoid using excess organizational objects.
Once you’ve designed all the layers for your NDS structure, you should review the design. Does it make sense? Have you forgotten anything? Is it too detailed? Make any necessary changes, and then review the design again, and again, and again, until you’re satisfied with the structure.
As I mentioned earlier, this is just an overview. If you’re lucky enough to create an NDS design from scratch, or you're revising a current design, I recommend taking some time to learn how to design a solid NDS structure. The results will be well worth the effort.
Check out these resources if you’re seeking more information on NDS:
- The Complete Guide to Novell Directory Services, by David Kearns and Brian Iverson
- Mastering Novell Directory Services, by DavidKearns
Steve Pittsley is a desktop analyst for a Milwaukee, WI, hospital. He enjoys playing drums, bowling, and most sports.If you'd like to share your opinion, please post a comment below or send the editor an e-mail .