Novell eDirectory Design and Implementation

Chapter 2: Design and Implement an eDirectory Tree Structure

 

Objectives:

This chapter introduces the process of designing an eDirectory tree. The objectives important to this chapter are on page 2-1:

  1. Identify Fundamental Directory Design Factors
  2. Create a naming standards document
  3. Design the upper layers of an eDirectory tree
  4. Design the lower layers of an eDirectory tree
  5. Finalize the design of the lower layers
  6. Install eDirectory and Build a Tree
Concepts:

Identify Fundamental Directory Design Factors

Page 2-1 presents a list of reasons for creating a good design:

  • Partitioning and replication become better and easier - more on this later
  • A well designed tree accommodates growth
  • Well designed trees can be merged more easily
  • Network services are more easily accessed in a well designed tree
  • A well designed tree can be navigated with ease

A network should be designed to be efficient, fault tolerant, secure, and scalable.

Several benefits of a good design are:

  • easy for users to locate and access network services
  • easy for administrators to name, locate, and manage network resources
  • supports improved performance and fault tolerance
  • easy to implement security
  • scalable

Design is an ongoing process. You should realize that designs must serve the needs of the organization, which will change over time.

Two design principles:

  • Part of a good design will be based on the organizational structure of the company. This is called the Organizational Design.
  • Part of the design will be based on the network layout of the company. This is called the Technical Design.

Regarding Organizational Design, some tasks/concerns are:

  • obtaining or creating an organizational chart of the company
  • deciding what skills will be needed for this design project
  • recruiting personnel with the needed skills from within the organization
  • managing the design project

Regarding Technical Design:

  • the text will discuss technical rules in each chapter
  • the text will present optimization guidelines

You may consider these design processes to be two sets of principles that must be pursued together.

Create a Naming Standards Document

Page 2-7 proceeds to a major task in this procedure, creating the Naming Standards Document. It is easy to pass over this task, but it should be given some care. Anyone who has worked in an environment in which multiple individuals can create eDirectory objects can talk about the confusion caused by people not following a standard. A set of standards should do the following:

  • Make browsing and navigation of the eDirectory tree easy.
  • Make maintenance of the eDirectory tree easy.
  • Make merging separate trees easy.
  • Make the creation of unique eDirectory object names easy.
  • Avoid special characters in names that may not be supported by all operating systems.

Page 2-10 shows an example of a naming standards document. It is not a perfect example. You should spend some time considering it, to discuss what shortcomings you perceive in it.

Page 2-12 continues the naming standard document with details on the various properties of objects that may be created. When you consider the number of properties in each of the various objects, you will begin to see the length of this document.

Design the Upper Layers of an eDirectory Tree

Page 2-19 begins the discussion of the chapter's second objective: designing the upper layers of the tree. The upper layers should not be subject to change except in merges. For this reason, careful design is recommended and some rules are provided:

  • Use a single tree. This is the default in a new installation, it is simpler than having multiple trees, and it allow easier administration by few staff. Large enterprises composed of multiple companies may have need of multiple trees, but Novell recommends not doing this unless necessary for your organizational needs.
  • Use a pyramid design. This provides a hierarchical structure that is intuitive to most users.
  • Name the eDirectory tree sensibly. Short and descriptive names are preferred. Unique names are necessary, should mulitple trees exist in the same network. Several key points appear in the text. Each tree must have a unique name which is also the name of its [Root]. The text makes a point of observing that the [Root] is not considered a layer in the tree, perhaps because you have no choice in creating it. Finally, it is observed that a tree's name can be changed with the DSMERGE utility.
  • Create a single organization object. This is usually the case, and the text makes a point that naming conventions can be enforced easily through a ZENworks import policy applied to a single organization object. Three reasons are suggested for not having a single organization: if your network contains multiple companies; if you must represent distinct, separate business units; and if you must obey some rule or regulation about keeping organizations separate.
  • Create first level organization units that represent the network infrastructure. So what does that mean? You want to know how the network is connected. First level Organizational Units should represent entities that are separated by WAN links. If there are no WAN links, consider the alternatives on page 2-23:
    • Location - The first illustration in this set shows three locations separated by WAN links. Note that the text states this is also appropriate if the locations are in separate buildings, or separate LANs. The resulting tree structure on page 2-25 is practically the reverse of the one we will see based on function..
    • Function - the illustration on page 2-30 shows a tree that branches from its Organization to three Organizational Units: Admin, Sales, and Research. Each of these three then branch into three sub-containers based on services for users. This kind of design should only be used if the network is only at one location (it would be all right if the three locations above are just floors in a building), and has 250 or fewer users.
    • Combination Approach - This approach is shown in the tree on page 2-32. It begins with a functional approach for the first two Organizational Units, then the next layer of Organizational Units represent locations (cities and regions).
  • Many subordinate references may be created if your network has many locations at the first level. They can be minimized if you create a layer between these Organizational Units and the Organization. The intermediary layer would group the location OUs by region or function.
  • Some exceptions to rules about using a location based design are:
    • High speed WAN links, that are reliable and stable may allow your design to be based on function instead of location.
    • A network that exists at one location and should not expand will accommodate a functional design.
    • Remote locations with dial-up connections may be designed as separate trees unless they need constant contact with the network.
Design the Lower Layers of an eDirectory Tree

The discussion of designing the lower layers of the tree begins on page 2-38. Note that this phase of the design may need to be done in several versions before it is finally right.

Lower layers may resemble an organizational chart, because objects should be placed together in containers to grant common access to each other. Users who work together often need access to the same network resources, so their workgroups will resemble their container structures. A list of concerns appears on page 2-38. These concerns should be addressed at this stage.

Finalize the Design of the Lower Layers

Three factors are presented on the next several pages that affect your lower layer design. (Note that "network infrastructure" is not one of them: this affects upper layer design.)

  • Administrative approach - Will all of your network locations be administered by one administrator (or very few)? If so, you are using the Centralized approach. This can be facilitated by placing all your servers in one container. As noted in the chart on page 2-40, this approach is simple to administer and provides more control, but only works well for LANs and MANs, and requires special setup for fault tolerance.
    If you have multiple administrators, especially at multiple layers of the tree, you are using the Decentralized (Distributed) approach. This approach works better for WANs, and may use IRFs to limit the rights of administrators at higher levels.
  • Login scripts - Users are often placed in the same lower level containers to allow them to use the same login script. Resources that can be managed through login scripts include menus, applications, drive mappings, printers, and environment variables.
  • Container sizes - For eDirectory version 7, the number of objects in a container determine its size. Page 2-43 offers a rule of thumb: no container should hold more than 3500 objects. Note, it does not say 3500 users. A container with 3500 users in it would likely have hundreds of other objects in it as well: printers, queues, servers, volumes, etc. The text also states that this limit does not apply to eDirectory version 8.5, which has no limit on the number of objects in a container. This is a bit misleading, however. eDirectory 8.5 does not limit the size of your network, but your hardware (e.g. server processor) may do so.
Install eDirectory and Build a Tree

eDirectory can be installed on Novell servers, Windows servers, and on Linux servers. When it is installed you should expect to create the following objects:

  • Admin user object
  • Organization object
  • Server object
    • NetWare and Linux will use the current name of the server as the basis for the server object name. Windows 2000 allows you to provide the name of the server object.
    • If you need to change the name of a server object, you cannot do so in ConsoleOne.
  • Volume object - note: this object is not created if eDirectory is running only on a Windows or Linux server.

Other server objects can be created to represent other servers in your network.