To implement NDS on your network, you need to first complete the following general tasks:
This list should include all users, servers, print queues, and other Directory tree objects that will be installed. When listing Directory tree objects, establish a naming standard. By using a standard when creating object names, you can make it easier to recognize objects by type and name.
Use similar guidelines when naming all objects. The conventions you use should be consistent across the entire Directory.
Consult ``NDS objects and properties standards'' for help in creating this document.
You can decrease network traffic by physically locating objects near the users who will access those objects. This keeps data flowing in relatively small segments, rather than travelling across several routers and cable segments where traffic could become congested.
If you plan to use bindery services, centralize the objects that bindery services users will use in a common container. This makes managing the context of bindery services objects easier.
When organizing your Directory tree, consider the following possible organizational structures:
Base the Directory tree on the structure of your organization. When planning the Directory, you can begin with an organizational chart, and then modify that chart according to network access requirements and other factors.
Use geographic locations as Organizational Units. Then you can use organizational charts for each location to organize workgroups or departments at each location.
Organize your Directory tree by function if users or groups in your organization perform similar functions. Users with similar functions are likely to share servers and other resources, so it makes sense to group them together.
Group bindery services users within containers (bindery contexts) defined by workgroups, shared resources, and information usage and exchange. By placing similar users in the same container object, you make it easier to give bindery services users access to the resources they need.
Use the scoadmin(1M) Directory Services Install utility to install NDS (see ``Directory Services Install''). During this process you are prompted to specify the root context and tree name.
You must also set the server context within the Directory tree. If you want to access information on the global internetwork, add a country code when setting the server context and a Country object will be created directly below the [Root] object.
Keep in mind that your network hardware supports both file services and Directory services. If you add large numbers of leaf objects, such as users or print queues, to a single container object, you might need to increase the amount of shared memory on the server.
Populate the Directory tree structure as follows:
Place leaf objects in containers that provide the best access for the resources, groups, and users that use them.
For example, a NetWare server object that stores a replica of each partition on the network can be placed in an Organization object for more efficient network management. Other servers and print queues can be placed in Organizational Units with the users or groups that utilize them.
Create Profile objects that provide organization or department login scripts in the appropriate container objects for groups of users who need similar work environments but who are not located in the same container object.
Implementing objects this way allows for easy, centralized control at the top of the tree and local control of the lower levels. At each container level, a User object with supervisory rights has authority over the objects within that container object.
To add a new server, use the scoadmin Directory Services Install utility to install and set the appropriate context within the Directory tree (see ``Directory Services Install'' for details).
Security features can be set up in NetWare Administrator or NETADMIN (see ``NETADMIN'').
The number and location of container objects, partitions, and replicas determine the type of time servers you should create for your network.
Time synchronization is set up and managed with scoadmin NetWare Setup or nwcm(1Mipx).
For security, optimum performance, and reliability, it is a good idea to group servers within container objects, depending on department or site. If, for example, your organization is spread over three cities, specify a site-specific container object as a bindery context for the following reasons:
This allows the network supervisors to control local administration; updating local servers, adding or deleting users, installing new equipment, and performing other tasks that are often best handled on a local basis.
If, for example, network supervisors in three different cities have supervisor rights over the same container object (bindery context), each of them can assign rights that the other two would disagree with.
If, for example, users in London and Tokyo had their User objects in a bindery context served by a server in New York, every data transmission would take place over WAN links. This would likely result in decreased performance and create the potential for other problems.
To enable bindery services for objects within a container object, you need to set a bindery context to that container. To specify a bindery context for a server, use scoadmin NetWare Setup or the nwcm(1Mipx) utility.
Use PARTMGR (see ``PARTMGR'') to manage the Directory databases on your network.
Create most of your partitions at lower levels of the Directory tree. Workgroup boundaries generally determine the number of partitions required in a tree. You should partition your tree in relation to the use and physical locations of network resources. You should create partitions only if they provide better performance or fault tolerance to the network and tree.
Before performing any partition operation, ensure that the state of synchronization for all servers affected by the operation is stable. The following table provides recommendations for determining which partitions will be affected by what operation:
| Partition Operation | Partitions Affected |
|---|---|
| Create, add, delete a partition | Target partitions |
| Change the replica type | Target partitions |
| Rebuild any partition replica | Target partitions |
| Join partitions | Parent and child partitions |
Do not create too many replicas of the [Root] partition and other parent partitions. Otherwise, you force NDS to keep track of more child partition references than necessary. The appropriate number of replicas for any given partition depends on your environment.
If you create your Directory tree with the network user and resources in mind, you will find that the most efficient use of replicas (reducing WAN traffic while providing fault tolerance) means you should not need many replicas.