NDS tree design made easy
Ron Nutter
Published: 15 Apr 2003 13:34 BST
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 won't be traumatic.
If you haven't designed an NDS tree before, don't let the task overwhelm you. One thing you'll learn is that there is more than one right way. Even Novell has gone through several design theories about NDS design as it learned how to best implement NDS. I'll describe the 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. But you may find that the task can become very political as different departments and divisions of your company vie for their own interests. For example, you may think that it makes sense to place 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 might object. Start by getting a copy of the organisational chart. This, along with some careful research, will give you a feel for the geographic and political landscape.
If your company will have a network that spans multiple locations, find out where the departments are and whether any departments exist in multiple locations. Both the geography and departmental function will affect how you set up the tree. This information will also help you partition the tree to minimise network synchronisation 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 organisational unit objects (OUs) that are nested below the organisation 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 better.
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. If you minimise synchronisation 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 organise your tree. If you use OUs in moderation and plan carefully before setting them up, 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 lets you do several things. First, you can centralise 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 organisation chart and your NDS tree.
Previous
Did you find this article useful?
79 out of 150 people found this useful
- Share this article:
