Enterprise Software

Beginner's Bonsai: Designing an NDS tree

Deploying Novell's Directory Service doesn't need to be traumatic. This Daily Drill Down will show you how to design an NDS tree that will be a perfect fit for your company's growing and changing needs--even if you're an NDS newbie.

Training a Bonsai tree into exactly the right shape is not that much different in terms of planning than creating a perfectly shaped Novell Directory Service (NDS) tree. As with the Bonsai tree, the trick to successfully implementing an NDS tree is doing it right from the beginning. By getting it right the first time, you’ll ensure that any future changes you need to make to your NDS tree later won’t be traumatic.

If you haven’t designed an NDS tree before, don’t let the task overwhelm you. One thing that you’ll learn is that there is more than one right way to set up an NDS tree. Over the years, even Novell has gone through several different design theories about NDS design as it learned how to best implement NDS. This Daily Drill Down will describe the different considerations that will make or break the success of your NDS tree.

Start with office politics
You would think that beginning to build an NDS tree would be fairly straightforward: Pick a design and get to work. However, you may find that the task can become very political as different departments and divisions of your company vie for their own best interests. For example, you may think that it makes sense placing all of the users at a given location in one container; however, when a manager at HQ sees that his users “belong“ to a rival’s container, he or she might object. Start by getting a current copy of the organization chart for your company. This, along with some careful research, will give you a feel for the geographic and political landscape in which you’ll be planting your tree.

If your company will have a network that spans multiple locations, you’ll want to find out what departments are where and if any departments exist in multiple locations. Both geography and department function will impact how to you initially set up the tree. Just as important, this information will help you partition the tree to minimize network synchronization traffic relating to changes to NDS information.

Flat trees equal easy maintenance
The flatter a tree is, the easier it will be to manage. “Flatness” refers to the number of organizational unit objects (OUs) that are nested below the organization object from the root of the tree and subnested beneath other OUs. Although you may not have a choice about how you nest OUs in your tree for political or geographic reasons, the flatter the tree, the easier it will be to maintain.

Novell’s current, generally accepted NDS design principle recommends that you have one container per location. To make this design work, Novell assumes that you’ll have one server per location.

At each location, you’ll partition the NDS tree. Partitioning NDS allows you to keep the traffic on the WAN to a minimum. By minimizing synchronization traffic on the WAN, more bandwidth is available for users.

Using OUs to keep things manageable
Whether you have one location or a hundred, the more users or other objects you need to include in your tree, the more screens you’ll have to scroll through in NetWare Administrator when searching for an object. To avoid this, you can use multiple OUs to help organize your tree. If you use OUs in moderation and plan carefully before using them, you will still be able to maintain a relatively flat NDS tree. As the number of users in your NDS tree grows, you may find it convenient to have one OU for each department. Creating departmental OUs enables you to do several things. First, you can centralize users common to a department in the OU, making it easier to find them if you have to make changes.

Second, instead of having a group object for each department with an associated group logon script, you can create a departmental OU and place a logon script in the OU container. If you have logon script commands that are common for all employees in the company, you can put those commands in a container that is higher in the tree than the departmental OUs. If you put an include statement in the departmental OU logon script that points to the higher container, you can keep the logon script commands for a given container to a minimum.

Finally, creating departmental OUs makes it easier to justify your NDS structure. You can avoid a lot of political games by pointing out the similarities between the organization chart and your NDS tree.

Coming up with a naming standard for the NDS objects
Novell provides a lot of flexibility for naming NDS objects. However, if you are too detailed or descriptive in your naming, the end result could be too prohibitively long. Keep in mind that the longer the names of NDS objects, the more that you’ll have to type when setting up logon scripts and configuring workstations to log on at the correct point within the tree. Also, the more you have to enter, the more chances there will be to make mistakes. With all of this in mind, it is best to keep the names of NDS objects as short as possible while still being descriptive.

As you work with NetWare Administrator, you’ll notice that each NDS object has its own unique icon that can help you identify what type of object it is. When you name objects, remember to create unique names; NetWare Administrator won’t allow duplicate object names.

Even though NetWare Administrator uses a unique icon to identify an object, there are a couple of rules that I try to follow when creating NDS objects to help describe the objects further:
  • PQ_
    to start print queue names
  • PR_
    for printer names
  • PS_
    for print servers
  • FS_
    for file servers

Just like there isn’t one right way to design an NDS network, there’s no one way to set naming conventions. Be sure to write down the reasons you’ve chosen to name objects the way you have. That way, if someone questions your naming conventions, you’ll be able to explain your reasoning as well as what other options you considered and why you ruled them out.

Keeping time in sync
Just as important as properly designing your NDS is properly setting up your time synchronization layout. Servers that are serving as Master or Read/Write replicas of a partition have to know what the correct time is so that when transactions arrive that affect the NDS database, such as a user logging on, the transactions are applied in the correct order—even if they arrive out of sequence.

Time synchronization is what distinguishes Novell’s Directory Service from Microsoft’s Active Directory. In Novell’s Directory, the directory updates are handled in sequence by the time stamp that is a part of the record arriving at each replica server. In Active Directory, the server receiving the record assigns a serial number to it and applies it in the order it assigns the numbers. The time server keeps the Novell database in harmony on all of the servers in the tree.

The time server functions as an electronic clock that coordinates the time for all servers on the network. Novell uses the following hierarchy for time servers in NDS:
  • Single Reference
  • Reference
  • Primary
  • Secondary

Small networks can use a Single Reference server on the main server in the tree as well as one or two secondary servers, which can help get the time information to the workstations and other servers on the network. The only type of server in the Novell hierarchy that I haven’t actually seen in use on a NetWare network is the reference server. The reference server was initially intended to be directly attached to an atomic clock or a receiver capable of picking of WWV or WWVH, which are the two time reference servers operating on 5, 10, 15, 20, and 25 MHz by the U.S. Government.

The two time server types that you’ll see most often are the primary and secondary. When you have two or more primary servers, they will initiate a voting sequence between themselves to decide on what the correct time is and announce that to the other servers and workstations on the network. The secondary servers will look for a primary time server to decide what the correct time should be.

The size of your tree and how many partitions you have will determine which types of time servers you’ll use. One of your design criteria for the network should be to minimize the amount of traffic going between sites. This criterion includes time synchronization traffic. Therefore, I would recommend at least one primary server in each partition.

When you configure time servers at remote locations, make sure the server with the Read/Write replica references the primary time server at its location. By using the Configured Time Sources option in the server’s Monitor.NLM, you can point the primary time servers to each other and point the secondary time servers to the primary time servers nearest them. By setting up time synchronization in this manner, you reduce the amount of service advertising that can occur when one type of time server is trying to find another one.

Trick of the trade
Here’s one trick that you probably won’t find in the manual or in any of the TIDs on support.novell.com. When using the Configured Time Sources option in MONITOR.NLM, you need to put a :123 after the TCP/IP address or fully qualified DNS name of the time server that you are going to reference—if it’s from an external time sources. If you are pointing one NetWare server to another, you don’t have to use the :123; the TCP/IP address will work just fine by itself.

Get planting…um…planning that tree!
The information in this Daily Drill Down may seem a little overwhelming, but if you take it one step at a time, you’ll do fine in designing your NDS tree. Keep in mind that there is no one way to design a tree. The best tree design is the design that works for you.

Editor's Picks