Designing Your Company's NDS Tree
Articles and Tips:
01 May 1998
Editor's Note: "Technically Speaking" answers your technical questions, focusing on issues that affect network administrators. To submit a question for a future column, please send an e-mail message to nwc-editors@novell.com, or fax the question to 1-801-228-4576.
Over the past several years I have installed NetWare 4 on single-server networks, multiserver networks at a single location, and multiserver networks that span multiple locations. With each installation, I have tried to figure out the best way to design a Novell Directory Services (NDS) tree.
First, I read all that I could about NDS, paying particular attention to NDS tree design. Unfortunately, most of the information I read focused primarily on theory--providing more information than I needed about what and why and not enough information about when and how.
This article provides practical guidelines to help you design your company's NDS tree. Although this article does not replace a good working knowledge of NDS, it gives you a starting point for understanding NDS tree design.
BUILDING AN NDS TREE
You must first decide how to build your company's NDS tree. Should you migrate users and network resources from a NetWare 3 server to the NDS tree? Or should you migrate only data and create new NDS objects for users and network resources?
When you upgrade a NetWare 3 server to NetWare 4, users and network resources are moved to the NetWare 4 server in a flat, bindery-style configuration. (In other words, the NDS objects for all users and network resources are placed directly under the [Root] object.) Although migrating users and network resources is an easy way to start building an NDS tree, I would recommend against using this approach. You may migrate hundreds, if not thousands, of old, unused bindery objects that have been created over the years your company's network has existed. You may also encounter problems if some of these objects have been corrupted or orphaned. Corrupted bindery objects can propagate unresolved external references throughout the NDS tree, which can slow down performance. Orphaned bindery objects, on the other hand, cannot be managed or deleted from the NDS tree. (Bindery objects contain references to other bindery objects.Anorphaned bindery objectis one that has lost its references.)
If you decide to migrate users and network resources from a NetWare 3 server, you must clean up the NDS tree after the migration process is completed. For example, you should manually add, delete, and move NDS objects as needed.
In addition, you should consider using Computer Associates' DS Standard NDS Manager, which helps you import bindery objects into NDS and design the structure of the NDS tree. With DS Standard NDS Manager, you can design your company's NDS tree and test this design before you migrate users and network resources. As a result, you can perform NDS operations--such as adding, deleting, and moving NDS objects--and determine the ramifications of these operations before you implement them in the NDS tree. If you use DS Standard NDS Manager to maintain the NDS tree, you get the added benefit of being able to use this product to rebuild the NDS tree in the event of a catastrophic failure. (For more information about DS Standard NDS Manager, visit http://www.cheyenne.com/directory.)
DESIGNING AN NDS TREE
Next, you must decide how you want your company's NDS tree to look. This step is the most troublesome part of implementing a NetWare 4 network. You plan, you follow the books, and you still may not know the best NDS tree design.
After years of installing NetWare 4, I finally stumbled across an NDS tree design that has, so far, fit every company I have worked with--from companies with a single server at one location to companies with multiple servers at multiple locations. This design works because it is simple and easy to understand.
Of course, I begin by creating a [Root] object in the NDS tree. I then create an Organization (O) object, assigning this object a name that is meaningful to the company. For example, if a company had a single business unit, I would use the company name. (See Figure 1.) If the company had multiple business units (such as Saturn, Dodge, and Chevrolet, which are part of General Motors Corp.), I might name the O object Enterprise or Corporate.
Figure 1: This NDS tree would work well for a company with one location.
If your company has one location, you can skip to the "Creating OU Objects for Business Units" section. If your company has multiple locations, you should continue with the next section.
Creating OU Objects That Correspond to Locations
If your company has multiple locations, you then create an Organizational Unit (OU) object under the O object for each location. For example, I once supporteda Utah-based company with offices in Salt Lake City, Provo, and Draper. In this case, I created an OU object for each location, naming these objects OU=SLC, OU=Provo, and OU=Draper. (See Figure 2.)
Figure 2: If your company has multiple locations, you create an O object under the [Root] object, and you then create OU objects for each location. Under these OU objects, you create high-level OU objects for specific types of NDS objects, such as Server and User objects.
If your company has offices in different states or countries, you can use state or country names. For example, if I supported a multistate company, I might create OU objects for California, New York, and Texas. If the company had multiple offices in each state, I would then add another layer of OU objects. For example, under the California OU object, I could create a Sacramento OU object and a Los Angeles OU object.
Creating OU Objects That Correspond to Business Units
After you create OU objects for each location, you create OU objects for the business units at each location. If your company has only one location, you create OU objects under the Oobject for each business unit.
At this point, my guidelines change from others I have encountered. You create what I call high-level OU objects, which contain specific types of NDS objects. For example, you could create a high-level OU object for User objects, Group objects, Server objects, or Printer objects and Print Queue objects. (See Figure 2.)
You can then manage login scripts, access controls, and trustee rights more easily. For example, if you wanted users in the Sales department to access particular printers, you could add the Printer objects to the Sales department's Printers OU object. Next, you could grant the Users OU object the necessary rights to the Printers OU object. You could also enable users in the Marketing department to access one of these printers by creating an alias to the Printer objectin the Marketing department's Printers OU object.
CONCLUSION
Using these guidelines allows you to expand a NetWare 4 network as needed. You can easily add locations and business units and merge NDS trees.
If your company is large, you can set up an administrator for each location or for each business unit. You can also easily identify network resources, such as servers and printers, within each business unit. Simply put, these guidelines make it easy to maintain your company's NDS tree.
Mickey Applebaum has worked with NetWare for 14 years. Mickey provides technical support on the Internet for The Tech Forums Inc. (http://theforums.com).
NetWare Connection,May 1998, pp.34-35
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.