Novell is now a part of Micro Focus

NDS Design for ZENworks and NDS for NT

Articles and Tips: article

Blair Thomas
Senior Consultant
Novell Consulting

01 Jun 1998


Provides recommendations you can use to build your NDS tree, including specific design instructions for ZENworks and NDS for NT. Also includes information on how to design, partition, and replicate NDS.

Introduction

Novell Directory Services (NDS) design can be summarized in a couple of basic guidelines which, if followed, will give you an efficient and successful tree design regardless of the type and size of your network. We strongly recommend that you learn and follow these design principles, so you can be confident that the NDS tree will meet the needs of your network environment.

The purpose of this article is to give you specific design recommendations you can use to easily build your NDS tree. In addition, this document contains specific design instructions for ZENworks and NDS for NT. For example, ZENworks introduces new workstation objects into the NDS tree, which could potentially double the number of total objects in your NDS tree.

NDS for NT integrates Windows NT domains into the NDS tree, and adds all of its users. As a result there needs to be specific design recommendations to handle ZENworks and NDS for NT. Before we introduce the additional requirements of ZENworks and NDS for NT, you must first learn how to design, partition, and replicate NDS for your environment.

NDS Design Guidelines

The basic NDS tree design can be done very quickly once the concepts are understood. An NDS design for companies both large and small can be mapped out in literally hours. In addition, having a plan before beginning an installation will save you time in the long run. Your design can even serve as your installation guide. No two trees will be exactly alike and yet all trees have common characteristics that can be summarized into the following guidelines.

Tree

  1. Design the top of the tree based on WAN infrastructure

  2. Design the bottom of the tree based on organization of network resources

  3. Do not use global groups or groups that have users across WAN links

Partitions

  1. Partition the top of the tree based on the WAN infrastructure

  2. Do not create a partition that spans your WAN

  3. Partition around the local servers in each geographic area

  4. Partition the bottom of the tree based on size (1000-1500 objects)

Replicas

  1. Maintain three replicas for fault tolerance

  2. Replicate locally (if possible)

  3. Replicate to provide bindery service access

  4. Place master replica on servers at hub sites not remote sites. This provides optimal partition operations.

A balance of replication for fault tolerance and performance can be achieved if the above rules for partitioning and replication are followed as closely as possible. NDS was built to be scalable to meet the growth needs of your network environment. Partitioning and replication is the method by which NDS can be logically segmented for greater efficiency across multiple NetWare 4 servers.

The specific design rules for partitioning and replication of Directory Services can be separated into two different categories depending on your specific implementation requirements, hardware, and knowledge level of your staff. The two categories defined for the partition and replica design rules are the Quick Design and the Advanced Design options.

We strongly recommend that you always use the Quick Design numbers for the design of your NDS tree. You should only use the Advanced Design numbers in extreme situations. Your NDS tree will work better and more efficiently if you always use the Quick Design rules.

Quick Design (strongly recommended):


Partition size

1000-1500 objects

Number of child partitions/per parent

10-15 partitions

Number of replicas/per partition

2-5 replicas (typically 3)

Number of replicas/per server

7-10 replicas

Number of replicas/per Replica Server

30 replicas (see note)

Minimum server hardware

Pentium 100+Mhz with 64MB of RAM

Advanced Design (use only in extreme situations):


Partition size

3500 objects

Number of child partitions/per parent

35-40 partitions

Number of replicas/per partition

10 replicas (typically 3)

Number of replicas/per server

20 replicas

Number of replicas/per Replica Server

70-80 replicas (see note)

Minimum server hardware

Pentium Pro 200+Mhz with 128MB of RAM

Note: A Replica Server is a dedicated NetWare 4 server that only stores NDS replicas. This type of server is sometimes referred to as a "DSMASTER Server." This configuration has become popular with some companies that have a lot of single server remote offices. The Replica Server provides a place for you to store additional replicas for the partition of a remote office location.

The number of replicas on any server is limited by the fact that the Replica Synchronization Process must be able to complete in 30 minutes or less. The factors that affect the time it takes to complete the synchronization are:

  1. CPU speed of the replica server

  2. Number of replicas

  3. Number of objects in each replica

  4. Size of each replica ring

  5. Location of replicas in the replica ring (local or remote)

  6. Speed of the WAN links connecting remote replicas which includes bandwidth and round trip time (such as avoiding long satellite latency)

  7. RAM on the replica server

  8. Frequency of inbound replica synchronization

Disk Space Recommendations

As more products are being written to extend the NDS schema, it is reasonable to assume that disk space consumed by NDS will continue to get larger rather than smaller. For future server planning, we recommend that you create a SYS volume size of at least 4GB in order to accommodate future growth. If you do not have any current guidelines for the size of your SYS volume, you should consider our 4GB recommendation. For this recommendation we have tried to consider the current and future product demands. Besides ZENworks and NDS for NT, other products as they are released will continue to place space demands on volume SYS. For example, in NetWare 5, Java is available which runs directly from the SYS volume with memory paging required. GUI Server interfaces, as expected, will require a large chunk of disk space.

Although we have not described all the products that could affect disk space, we do know that running out of disk space on volume SYS is the worst thing that can happen. For this reason, we recommend 4GB for the SYS volume to keep you safe for at least three years. This recommendation assumes that network printing has been moved off of volume SYS. If printing remains on SYS then the amount would vary greatly.

NDS Design for ZENworks

In addition to the basic NDS design rules, the following section describes how you can fine-tune the design guidelines to efficiently accommodate ZENworks with its objects. The specific design guidelines do not require you to redesign your tree but simply add to the existing design. If you designed your NDS tree correctly (according to the recommendations given previously) it should be flexible enough at the bottom of the tree to handle the increase of objects that ZENworks offers.

As you may know, ZENworks is made up of several important products: Novell Application Launcher (NAL), Workstation Manager, Inventory, and Remote Control.

ZENworks offers the following objects:

  • Application objects

  • Application folders

  • Policy Packages

  • Workstations (not Computer objects)

  • Workstation Groups

In order to design your NDS tree with these objects, we recommend that you continue to follow the NDS guidelines as described above. Nothing should change. The only issue should be where to place the objects. If the container or partition does not have room to accommodate the increase in new objects, you will need to create new containers and partitions appropriately. These changes will only affect the bottom of the tree. So the main questions are:

  1. Where to place the new objects?

  2. Do I use existing department containers or same container as users?

  3. Do I use OU=APPLICATIONS, OU=WORKSTATIONS, OU=USERS, etc?

In order to answer each of these questions, let's consider each product feature individually.

Application and Application Folder Objects

The Novell Application Launcher, with accompanying Application and Application Folder objects, enables you to quickly and easily distribute applications to users' workstations and manage those applications as objects in the NDS tree. Users access the applications that you assign them using the Application Launcher Window and Application Launcher Explorer components. The main NDS design question is:

Where do I place the Application and Application Folder objects in the tree to support the users?

Recommendations

We recommend that you place or create the application objects and the supporting group objects close to the users who will be accessing them.

The application folders are only used by the network administrators. The user never accesses an application folder object. Therefore, you can place the application folder objects in the most convenient location for the administrators. The information in the application folder is cached in each of the application objects which are linked to the application folder.

This method reduces the NDS traffic needed to maintain the application folders with their associated applications.

For networks with multiple locations across a WAN, you should create the application objects in the NDS container that represents the physical site or location.

For example, the objects would be placed in the OU=LOCATION container. In addition, you should create individual application objects for every location in your WAN infrastructure. The reason for creating new application objects for each location is for better scaleability across the network.

We recommend that you avoid designing ZENworks so that the users have to access the application objects across the WAN in remote partitions. Do not create one application object for your entire network, if it will be accessed from multiple locations across the WAN.

On the other hand, if your network is contained in a single LAN infrastructure, you could create just one application object per application program.

In addition, you should create a different application object to reference each application server that is installed. If you have multiple application servers at one location or site, we recommend that you create a ZENworks application object for each different application on each server. For example, if you have three servers holding applications that will be used by your users, then create a ZENworks application object for each program on each server.

You can use the following format to name the ZENworks application object:

<PROGRAM_NAME>_<SERVER_NAME>

See the following table:


NetWare Server Holding Applications

Matching Application Objects

PRV-APPSRV1

WP_PRV-APPSRV1 (Word Processing application)SS_PRV-APPSRV1 (Spread Sheet application)EM_PRV-APPSRV1 (E-mail application)DB_PRV-APPSRV1 (Database application)

PRV-APPSRV2

WP_PRV-APPSRV2 (Word Processing application)SS_PRV-APPSRV2 (Spread Sheet application)EM_PRV-APPSRV2 (E-mail application)DB_PRV-APPSRV2 (Database application)

PRV-APPSRV3

WP_PRV-APPSRV3 (Word Processing application)SS_PRV-APPSRV3 (Spread Sheet application)EM_PRV-APPSRV3 (E-mail application)DB_PRV-APPSRV3 (Database application)

This configuration enables you to set up and effectively use the fault tolerance and load balancing features built into the ZENworks product.

In order to manage these similar application objects pointing to different servers, use the new application object copy feature that is available in ZENworks. When creating a new application object, you are given the option to create it from an existing application object in the tree. After copying an application object, you need to simply change the source server, path, drive mapping, and other properties (as necessary).

It is not recommended that you use a generic NDS object copy utility to create new application objects. Always use the application object copy feature in ZENworks.

Group Objects

Group objects in NDS are used for many different purposes; one use is to grant user rights. With ZENworks, groups are often created to grant users rights and associate them to application objects. The group objects used to grant rights for ZENworks application objects need to follow the same design guidelines as the application and application folder objects themselves. Place the group objects with the associated application object. Never create a global group or group object that contains members that span physical locations.

Consider the following design rules for group objects:

  1. Create the group object in the same container as the associated application.

  2. Limit the number of members in the membership list to 1000-1500.

  3. Never span group membership across a WAN network.

  4. If possible, keep the users in the group in the same partition. The result is that you minimize external references and its associated network traffic.

Application Object Associations

For ease of administration, you can associate or assign the application objects to a user, group, or container. When the Application Launcher Window or Application Launcher Explorer starts, it searches for all associated applications from the user object. It next searches for applications associated to groups the user is a member of. And finally, depending on the "Container Levels" setting in the launcher configuration, it searches for applications associated to the parent containers.

The settings are as follows:


Setting

Description

-1

Reads all parent containers to the top of the tree for associated applications

0

Does not read any parent containers, searching is turned off

1

Only reads the immediate parent container for associated applications

2

Reads only two levels up, parent and parent's parent for associated applications

You can control the searching criteria used by changing the configuration in the Launcher Configuration property page in Configuration/Current Settings/Inherit Container Applications.

Recommendations

We recommend that for the best performance you use the following guidelines for establishing the associations to application objects:

  1. Set the searching to 0 or 1, which turns off searching or localizes the search just to the users' local container.

  2. You can set the searching to 2, if the parent and parent's parent are local to the user. Local means in the containers on the same LAN, not across the WAN network.

  3. Use the -1 (search to top of tree) setting sparingly; it should only be used on local area networks.

  4. If user access is across the WAN, restrict the searching of groups. The group searching can be turned off.

Another design consideration is using the Application object's Schedule property page to let you control when users are delivered applications. This is useful in the scenario where you want to distribute a large Service Pack to all users. For example, you do not want a large update to occur at 8:00 a.m. when all network users are logging in. In addition, you may not want this distribution to occur on weekends when there are no technical support people on-site.

For these reasons, we recommend that you consider making the Application object available Monday through Friday, spreading the network traffic load throughout the day. This can be accomplished by configuring the system to download the Service Pack at 8:00 a.m. during users' log in; however, make sure to set the "Spread from Start Time" to 180 minutes.

The application then becomes available on a random basis between the hours of 8:00 a.m. through 11:00 a.m. For more information, refer to context-sensitive Help on the Application object's Schedule property page.

Workstations and Workstation Groups

As previously mentioned, the advent of ZENworks and the use of the Workstation objects could potentially double the total number of objects in your tree. How does this impact the current NDS tree design guidelines? The answer is that the new objects should not impact any of the current numbers.

However, when creating the Workstations and Workstation Groups you should make sure that each container (Organization or Organizational Unit) has enough room to accommodate the new objects. More importantly, make sure that each partition still has less than 1500 objects per partition. These changes may require you to create new containers and partitions.

It is also extremely important that your NDS is healthy before you add the additional objects that ZENworks offers. In addition, make sure that each of your servers has the latest patches loaded.

Recommendations

Since the Workstation Import Policy defines where the Workstation objects are created in your NDS tree, consider the following guidelines:

  1. Create the Workstation objects in the same container as the user object, assuming this does not exceed partition number guidelines.

  2. Creating the Workstation objects in a single-purpose container (OU=WORKSTATIONS) has limitations

As a general rule, we recommend that you place the Workstation and Workstation Group objects with the accompanying users. Placing the Workstation objects with the users enables you to keep the NDS design flexible and efficient.

However, we recognize the fact that the Workstation objects are not going to be accessed by the users but instead by the client component itself. Therefore the speed of access is dependent upon the proximity of the physical workstation to the NDS partition and not the location of the user in the NDS tree.

Another issue is that the administrative staff will use the Workstation object to store the inventory for the physical machine. If your administrative staff is de-centralized with different groups handling different functions, you may want to create a separate OU=WORKSTATIONS to place the objects. This type of design enables you to assign certain network administrators access to manage just the workstations.

As the number of objects in the current partition grows, you can then partition off just the OU=WORKSTATIONS container as its own partition. The use of OU=WORKSTATIONS may be appropriate for some NDS trees only because the workstation objects are used exclusively by the network administrators and not the users.

We generally do not recommend that you create single-purpose containers to place similar resources together. For example, we would not recommend creating a container for all servers, users, printers, groups, org. roles, applications, policies, and others. The following design of the bottom of the NDS tree (under OU=LOCATION) is not recommended:

OU=LOCATION (SITE) OU=USERS OU=SERVERS OU=PRINTERS OU=GROUPS OU=ORG_ROLES OU=APPLICATIONS OU=POLICIES OU=WORKSTATIONS

Keep in mind that this design may seem to work if all the containers were in the same partition. However, we do not recommend designing your NDS tree using these single-purpose containers because of the following:

  1. Reduces user speed of access

  2. Bottom of the tree becomes inflexible

  3. Scaleability at the bottom of the tree is limited

  4. Further partitioning of containers reduces performance

  5. Designed for the administrators not users

These problems are magnified if the site or location grows to thousands of users, workstations, etc. As each OU is partitioned off, the performance and access is greatly reduced. Partitions are created to help NDS scale across the servers, which typically means that each partition will reside on different servers. As the replicas are moved off each server, the user's resources (servers, printers, groups, applications, policies, etc.) become dispersed reducing the speed of access.

In addition to the reduced access and flexibility, the network performance can be adversely affected with the higher number of external references that are created to track all the objects not physically residing on each server.

Policy Packages

There are several new objects offered by ZENworks called Policy Packages that enable you to manage users' workstations remotely and in a consistent fashion.

There are several different types of Policy Packages that can be created:

  • Container Package

  • WIN31 User Package

  • WIN31 Workstation Package

  • WIN95 User Package

  • WIN95 Workstation Package

  • WINNT User Package

  • WINNT Workstation Package

The Container Package is used to define how the client component searches in NDS for associated Policy Packages. The Container package can only be associated with containers. The User Policy Packages are either associated to users, groups or containers. The Workstation Policy Packages can be either associated to Workstations, Workstation Groups or containers. It is not possible to assign several Workstation Policy Packages to the same object. However, it is possible using User Policy Packages to assign several Policy Packages to the same object.

Recommendations

We recommend that you place the Policy Package objects close to the users or workstations that will be accessing them. For Policy Packages consider the following guidelines:

  1. Create the Container Policy Package at the highest level of the tree as needed. It should never exceed the location or site container.

  2. Create the User Policy Package in the same container as the users that will access it.

  3. Create the Workstation Policy Package in the same container as the workstations that will access it. If you have defined a single-purpose container for workstations (OU=WORKSTATIONS), place the policies in this container.

If user access to the Policy Package is across the WAN, restrict the searching of groups. The group searching can be turned off using the Search Policy.

NDS for NT

Since NDS for NT gives you the ability to integrate Windows NT domains directly into your NDS tree, it requires you to design your NDS tree to accommodate the new objects. New topics that we need to cover is how to design NDS trees with NT domains in them to support the NDS for NT product and also what is the best way to design domains.

Since the NT domain object in NDS acts as a group with a list of domain members, it takes on the NDS design characteristics of an NDS Group object. However, it is also a special NDS container object that holds NDS for NT Local Group objects, NDS for NT Global Group objects, and NDS for NT Workstation objects that are migrated from the original NT domain.

One of the unique design characteristics is the fact that you can create an NDS partition at the domain object. In other words, the NT domain object in the tree can become its own partition. The information that is stored in the partition created from the domain object is just the objects found under the domain. These objects are NDS for NT Local Group objects, NDS for NT Global Group objects, NDS for NT Workstation objects, and alias objects. The users that were migrated from the original NT domain can not be part of a partition created from the NT domain object in NDS.

The domain object in NDS can only be partitioned using NDS Manager. And, NDS Manager version 1.25 (and later) is the only version that will let you make this change. Versions of NDS Manager that shipped with NetWare 4 will not let you perform the operation. Version 1.25 of NDS Manager comes with the NDS for NT product and is installed automatically on the server that you select to install NDS for NT. Make sure that you are using the correct version of NDS Manager before trying to do the partition operation. To help reduce the confusion, you can copy the latest NDS Manager version (1.25 or later) to all of your NetWare 4 servers.

NDS for NT Design Guidelines

Since the domain object represents the original NT domain, one of the first design decisions is where to create or place the domain object in the NDS tree. We recommend that the object be placed in a container that is local to the domain users. For example, if there is a Windows NT domain in a specific site or location then the NT domain object in NDS should be created within the same location container of the NDS tree. In addition, the user objects should be migrated to the appropriate department containers under the same container as the domain object. You want to place the users in the container with the network resources that they use.

After you have decided where in the NDS tree the domain object and users will be placed, consider the following design rules for NDS for NT:

  1. Limit the number of members in the membership list of the NT domain object to 3000. This implies that you limit the number of users in the original NT domains to less than 3000 users.

  2. If possible, keep the users associated with the NT domain in the same partition. The result is that you minimize external references and its associated traffic.

  3. If you have multiple NT domains in your NDS tree, place each NT domain and its associated users in separate partitions.

  4. Create the NT domain object as its own partition when the number of objects contained is greater than 1000.

  5. Always have NDS for NT running on all Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs) supporting the Windows NT domain.

  6. The NT domain PDC or BDC must be in the same SAP domain as the NDS domains supporting the user objects.

* Originally published in Novell AppNotes

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.

© Copyright Micro Focus or one of its affiliates