NDS Design for ZENworks

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 4 May 1999

A wise Zen Master once said ?Z.E.N.works is only as good as your NDS design.?

OK, maybe we made up the source, but the counsel still stands:  Before you install Z.E.N.works, we strongly recommend that you follow a few simple guidelines to ensure that your NDS tree design is efficient and successful regardless of the type and size of your network. By following these principles, you can have confidence that the NDS tree will meet the needs of your network environment.

Z.E.N.works introduces several new objects into the NDS tree, which could potentially double the number of total objects in your NDS tree. That's why it's important for you to design your tree using the guidelines that we'll talk about. Before we get to the specific Z.E.N.works requirements, let's do a little refresher course on designing, partitioning, and replicating NDS for your environment.

NDS Design Guidelines
Basic NDS tree design is easy once you understand the concepts. In fact, you can map out a workable NDS design for any company, large and small, in just a few hours. When you consider the alternative of days or weeks of downtime and troubleshooting in the long run, a few hours of planning can go a long way. Plus, reviewing your NDS structure will make the Z.E.N.works installation go that much faster. While no two trees are exactly alike, the following guidelines apply to any NDS design:

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.

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).

1. Maintain three replicas for fault tolerance.

2. Replicate locally (if possible).

3. Replicate to provide bindery service access.

4. Place the master replica on servers at hub sites rather than remote sites. This provide optimal partition operations.

By following these rules as closely as possible, you can achieve a balance of replication for fault tolerance and performance. NDS was built to be scalable to meet the growth needs of your network environment. Partitioning and replication is the method you use to logically segment NDS for greater efficiency across multiple NetWare 4 or 5 servers.

There are two kinds of design rules for partitioning and replication of NDS, depending on your specific implementation requirements, hardware, and knowledge level of your staff: 1) Quick Design and 2) Advanced Design. We strongly recommend that you always use the Quick Design rules for the design of your NDS tree. You should use the Advanced Design rules only 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*

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*

Minimum server hardware: Pentium Pro 200+MHz, 128MB of RAM.

*A Replica Server is a dedicated NetWare 4 or 5 server that just 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 ultimate limiting factor for the number of replicas on any server is that the Replica Synchronization Process on the server 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 (e.g., avoiding long satellite latency)

7. RAM on the replica server

8. Frequency of inbound replica synchronization

Disk Space Recommendations
Although Z.E.N.works does not have an immediate impact on hard disk space, you may be wondering what size you should make your SYS volumes that will carry you for at least the next three years. As more and more products are being written to extend the NDS schema, it is reasonable to assume that the disk space that NDS consumes 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 Z.E.N.works 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 feel that a general recommendation of 4GB for the SYS volume will 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 of disk space would vary greatly.

NDS Design for Z.E.N.works
Now that you've given your NDS a basic health check and made modifications as necessary, you're ready to fine-tune the design guidelines to efficiently accommodate Z.E.N.works and its objects. Keep in mind that you don't have to redesign your tree, but simply add to the existing design. If you've taken the time to design your NDS tree correctly (according to the recommendations we gave you earlier) it should be flexible enough at the bottom of the tree to handle the increase of objects that Z.E.N.works adds.

Z.E.N.works is made up of several important products: Novell Application Launcher (NAL), Workstation Manager, Inventory, and Remote Control. The objects that Z.E.N.works adds are the following:

Application objects

Application folders

Policy Packages

Workstations (not Computer objects)

Workstation Groups

The issue now becomes where to place these 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 should I place the new objects?

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


To address each of these questions, let's consider each product feature individually.

Application and Application Folder Objects
The Novell Application Launcher component of Z.E.N.works, 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 (NAL.EXE) and Application Explorer (NALEXPLD.EXE) components. The main NDS design question is:

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

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

Application folder objects are used only by the network administrator to manage applications. The user never accesses an Application folder object. Therefore, place these objects in a location that is most convenient for you. The information in the Application folder object is cached in each of the Application objects that are linked to the Application folder object. This method reduces the NDS traffic needed to maintain the association between applications and application folders.

If your network includes multiple locations across a WAN, create Application objects in the NDS container that represents the physical site or geographical location. For example, you would place the objects in the OU=LOCATION container. In addition, you should create individual Application objects for every location in your WAN infrastructure. Doing so improves scaleability across the network.

Avoid designing Z.E.N.works so that the users have to access Application objects across the WAN in remote partitions. A good rule of thumb is not to create just one Application object if it will be accessed from multiple locations across the WAN. If your network is contained in a single LAN infrastructure, one Application object per application program works just fine.

It's also a good idea to create a different Application object to reference each application server that is installed. That is, if you have multiple application servers at one location or site, it's best to create an 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 an Application object for each program on each server. You can use the following format to name the Application object:


For example, if you have three NetWare application servers PRVAPPSRV1, PRVAPPSRV2, and PRVAPPSRV3, you could name your Application objects accordingly:


    WP_PRVAPPSRV1   (Word Processing application)

    SS_PRVAPPSRV1    (Spread Sheet application)

    EM_PRVAPPSRV1   (E-mail application)

    DB_PRVAPPSRV1    (Database application)


    WP_PRVAPPSRV2   (Word Processing application)

    SS_PRVAPPSRV2    (Spread Sheet application)

    EM_PRVAPPSRV2   (E-mail application)

    DB_PRVAPPSRV2    (Database application)


    WP_PRVAPPSRV3   (Word Processing application)

    SS_PRVAPPSRV3    (Spread Sheet application)

    EM_PRVAPPSRV3   (E-mail application)

    DB_PRVAPPSRV3    (Database application)

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

The best way to set up similar Application objects that point to different NetWare servers is by duplicating an existing Application object. The Duplicate Application object feature is one of the options available when you create a new Application object. After copying an Application object, use that object's property pages to change the source server, path, drive mapping, and other properties (as necessary).

We recommend that you NOT use a generic NDS object copy utility to create new Application objects. Always use the Duplicate Application object feature in Z.E.N.works.

Group Objects
Group objects in NDS are used for many different purposes. One purpose is to grant users rights. With Z.E.N.works, groups are often created to grant users rights and associate them to Application objects. The Group objects used to grant rights for Application objects need to follow the same design guidelines as the Application and Application Folder objects. For example, place Group objects among the associated Application objects.

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. To minimize external references and associated network traffic.

Application Object Associations
For ease of administration, you can associate or assign  Application objects to a user, group, or container. When the Application Launcher (NAL.EXE) or Application Explorer (NALEXPLD.EXE) 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 Container Levels settings are as follows:

-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. To access this feature,

1. Right-click the User or container object, and then click Details.

2. Click the Launcher Configuration property page.

3. Click the Edit button.

4. Click the General tab and the Set Application Inheritance Level option.

5. Specify the inheritance level, then click OK.

For optimum performance, use the following guidelines for establishing the associations to Application objects:

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

2. Set the level 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 LAN-only networks.

4. If user access is across the WAN, restrict the searching of groups. The group searching can be turned off by setting Read Groups for Applications (on the Launcher Configuration property page, General tab) to No.

Another design suggestion is to use the Application object's Schedule property page to let you control when applications are delivered to users. For example, suppose you want to distribute a large Service Pack to all users. 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 onsite.

For these reasons, 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 we said earlier, Z.E.N.works 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 objects. 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.

IMPORTANT: Make sure your NDS tree(s) are healthy before you add the additional objects that Z.E.N.works offers by using the guidelines that we discussed earlier. In addition, make sure that each of your servers has the latest patches loaded.

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 you don't exceed partition number guidelines.

2. Create 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 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 decentralized 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, organizational roles, applications, policies, and others. The following design of the bottom of the NDS tree (under OU=LOCATION) is NOT recommended:










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

1. Reduces user speed of access.

2. Creates inflexibility at the bottom of the tree.

3. Limits the scaleability at the bottom of the tree.

4. Reduces performance because of additional partitioning of containers.

5. Is for 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
Another kind of object that Z.E.N.works offers is the Policy Packages object, which enables you to manage users' workstations remotely and consistently. You can create the following different types of Policy Packages:

Container Package

WIN31 User Package

WIN31 Workstation Package

WIN95 User Package

WIN95 Workstation Package

WINNT User Package

WINNT Workstation Package

Use the Container Package 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 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.

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.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© Micro Focus