Novell eDirectory Design and Implementation

Chapter 1: Identify the eDirectory Design Process

 

Objectives:

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

1. Describe Basic eDirectory Concepts
2. Explain the roles needed to complete an eDirectory design.
3. Explain the major tasks in an eDirectory design cycle.
4. Explain eDirectory design implications for a scenario of two merging companies.

Concepts:

Describe Basic eDirectory Concepts

In previous versions of this course, Chapter 1 began with a review of eDirectory terminology. The following material is not in this chapter. However, students who have not studied Admin or Advanced Admin will want to know the following:

• Common Name - only leaf objects have common names. A common name is the object name of a leaf.
• Context - this can mean the position an object occupies in the Tree. Another way of saying this is that an object's parent container is its context.
• Distinguished Name - this is the fully descriptive name of an object, and every container object that specifies its context in the Tree. You can think of this as the path from an object up to, but not including, the [Root] of its Tree. Distinguished names typically start with a period, but in actual usage it is often left off. Distinguished names never use trailing periods.
• Current Context - this is your "current" position in the Tree, similar to the idea of a "current directory" in a file system.
• Relative Distinguished Name - this is just enough of an object's distinguished name to provide a usable, if not unambiguous, reference to it. A user may refer to an object in their own context by a common name, but an object in another context must be referred to by a distinguished or relative distinguished name, so that eDirectory may find it. The formula used in previous Novell texts is flawed. The formula reads that an object's relative distinguished name plus its context equal its distinguished name. This is ONLY true if the object's relative distinguished name is its common name. Sometimes this is simply not true. A relative distinguished name tells us everything we need to know to locate an object, based on our current frame of reference. The object's common name is its relative distinguished name, if and only if our frame of reference is the container that the object is in. If our current context is some other container, a relative distinguished name is longer.
• Trailing Periods - When you log in on a workstation, you have to specify a login name, which the system must find in a context in the Tree. If the workstation is set to log in to your context, you may log in with your common name, since it will be found in the first place the system will look for it (the current context). If, however, the workstation is set to log in to some other context, you may wish to log in with your distinguished name, since that notation specifies unambiguously where to find your object in the Tree. This should always work, but it is a lot of typing. A third way of logging in takes advantage of the fact that the Tree is shaped like a pyramid. Assume that I want to log in on your workstation. We both have User objects in the same Tree. Assume my distinguished name is .vincents.novell.instructor.computer_science.baker, while yours is .you.microsoft.student.computer_science.baker. Your workstation should be set to log in to the microsoft container. If I log in with my common name, the system will not find me. I can however, use this name:
  vincents.novell.instructor..
  This notation tells the system to look for a user called vincents, in a container called novell, in a container called instructor, which will be found in the Tree if you look in the place specified by the current context MINUS the two leftmost terms. Each trailing period means to drop one term from the left of the name of the current context, then use the remainder of the current context with the information given. It is actually faster to log in to a stranger's workstation with this method, if you know their context and yours.
• Typeful Naming and Typeless Naming - Typeful Naming means to include abbreviations for object types and equal signs preceding each object name. Using the example above, my typeful name might be .CN=vincents.OU=novell.OU=instructor.OU=computer_science.O=baker
  This example is a typeful distinguished name. Name can be typeful or typeless, distinguished or relative distinguished.
  
• Partitions - A Directory can be a large database. It may be too large to put on any one server. It is more secure and more practical to divide it into segments, called partitions, that are saved in several places. (This use of the word "partition" is completely different from the way it is used to describe a section of a hard drive. An eDirectory partition is not a hard drive partition.). We divide the Directory Tree into partitions using containers. A partition must have a container at the top, and may contain other containers as well. The partition is referred to by the name of the highest container in it. In the diagram below, the first partition we see is the [Root] partition. It is drawn so that it contains the [Root], the highest container object in the Tree. (This is not the only way to do it, just an example.) Any partition also contains all objects inside the containers it contains, unless another partition is made as a child of the first one. For example, the [Root] partition is the default partition in an eDirectory Tree. If it had been left alone, the [Root] partition below would have contained all objects in the Tree. However, a child partition was created: the EMA partition. We refer to the EMA partition as the child of the [Root] partition, since EMA partition branched from the [Root] partition. This also makes the [Root] partition the parent partition of the EMA partition. In this example, the EMA partition also has two child partitions: the NYC partition and the Tokyo partition.
  
  The topmost container in a partition is called the partition root. This is true for any partition. In the diagram above, we see that there are four partitions. The first is the [Root] partition, which contains [Root] only. The other three partitions are named for their partition root objects, the three containers at the top of each one. Note the naming standard:
  
  • All partitions are named for the topmost container in them, the partition root.
  • Only one partition may be called the [Root] partition, the one with [Root] at its highest point.

  
  It may be clearer if you think of the phrase "partition root" as really meaning the "partition's root", the place where we drew a line in the Tree and said it begins a new partition.

• Replicas - A Directory partition contains a lot of information, and it would be a shame to lose it, so Novell invented four kinds of replicas, most of which are copies of a given partition.
  
  • Master replica - a complete copy of a partition. The original copy is a master copy. Other copies may be made into master replicas, if the original is damaged. You may only have one master replica of any partition at any given time. Changes made elsewhere are passed here during eDirectory synchronization, and reconciled. A master replica can be used to make changes to the partition and to objects in it.
  • Read/Write replica - also a complete copy of the partition. There can be several of these copies, and two are created by default (if you have enough servers). This replica can be used to make changes to objects in it. Any partition changes attempted in it are passed to the master replica as requests. Object changes made here are passed to the master replica during eDirectory synchronization, and reconciled there. This replica can become a master replica if the master is damaged. It can also become a Read-Only replica.
  • Read-Only replica - also a complete copy of the partition. Multiples are allowed. All changes requested here are not made here, but passed to the nearest Master or Read/Write replica. Login to a Read-Only partition is possible, but not directly supported, as the request is passed on as above. This replica may become a Master replica or a Read/Write replica. This replica receives changes made in other replicas during synchronization. Since they have only limited use, Novell discourages the creation of Read-Only replicas.
  • Subordinate Reference - this is not a complete copy of anything. It is not really a copy at all, just a pointer to a copy of one of the above types. Subordinate References are created automatically. Any server that has a replica of a parent partition, and no replica of that parent's child, will be given a Subordinate Reference to the child. A subordinate reference does not support any changes, but forwards any change request to a Master or Read/Write replica.
  • Filtered Replicas - Filtered replicas contain only part of the information stored in a partition. They can be used to provide eDirectory information when only some information is needed. You can use ConsoleOne to create Filtered Read/Write replicas or Filtered Read-Only replicas.

Explain the roles needed to complete an eDirectory design

Page 1-2 begins a list of the Project Roles that need to be filled in a design project. Four roles are listed as needed most often. These are the Primary Roles:

• Project manager - in charge of the entire project
  Priorities:
  • Coordinate with the eDirectory expert
  • Acquire resources and funding
  • Oversee the design phase.
  • Coordinate and manage the implementation phase.
  • Know the organization.
  • Give direction to the project.

  Tasks:

  • Act as liaison between upper management and other departments.
  • Manage costs and time estimates.
  • Organize and schedule meetings.
  • Educate the organization on the changes and impacts of the design.
  • Make sure the design meets the organization's needs

  Concerns:

  • Efficient and effective design
  • Costs: Implementation, operation and licensing
  • Evaluation of software
  • Timeline for project
  • Make sure departments and team members communicate
  • User productivity
  • Training for users and administrators
  • Rollout of product: method and procedures
  • Oversee pilot
  • Post-implementation support
  • Acceptance of new product
• eDirectory Administrator- this person must have experience with eDirectory design
  Priorities:
  • Lead the project team.
  • Create the eDirectory tree design.
  • Design eDirectory security.
  • Design eDirectory Partitions and Replication
  • Choose project team members.
  • Obtain project needs from management and departments.

  Tasks:

  • Make sure design meets all needs.
  • Get team members to participate and provide input.
  • Meets timelines.

  Concerns:

  • Manage the expectations of management and departments
  • Coordinate login scripts
  • Coordinate with other groups.
  • Assign someone to document the design.
• Server Administrator - must be an expert in NetWare servers
  Priorities:
  • Maintain network performance levels.
  • Determine and plan the pilot implementation.
  • Implement the upgrade and migration (rollout) to other departments.
  • Ensure implementation of a logical time synchronization strategy.

  Tasks:

  • Plan server placement in the eDirectory tree.
  • Determine how to remove and add servers.
  • Meets timelines.

  Concerns:

  • Determine backward compatibility.
  • Calculate the disk space needed for new and existing servers.
  • Combine eDirectory tree design with the organization’s disaster recovery strategy.
• Connectivity Specialist
  Priorities:
  • Determine the effect of routing, protocols, telecommunications, or WAN structure on the eDirectory tree design.
  • Make decisions regarding the use of single or multiple protocols on the network.

  Tasks:

  • Deliver optimal internetwork traffic throughput
  • Advise the planning team about routing, protocols, and WAN structure.
  • Assist overall eDirectory design in regards to WAN traffic.

  Concerns:

  • Determine the efficiency of the design over the WAN.
  • Identify LAN/WAN bandwidth issues.
  • Establish the use of single or multiple protocols.
  • Determine which protocols to use on the LAN and the WAN.
  • Maintain seamless connections to hosts and other operating systems.
  • Identify current utilization figures.

One person may have several roles in a small organization. Also, it is possible that you will need to hire contract staff for some roles.

Some organizations need additional roles for their projects. These are Secondary Roles:

• Printing manager
• Workstation manager
• Application manager
• Online help personnel
• Security developers

Explain the major tasks in an eDirectory design cycle

Page 1-6 presents a chart of the eDirectory Design Cycle. This concept of a cycle will be familiar to those who know something about software or system development. In the chart shown in your text, note that there are four phases to the cycle:

1. Project Approach Phase
2. Design Phase
3. Implementation Phase

Each phase contains one or more procedures, which are further divided into tasks, steps, etc.

The Project Approach phase is discussed on page 1-7. The only procedure in it is covered in this chapter: Preparing for the eDirectory Design. Five tasks are listed:

• Polling the users and network personnel most impacted by the design
• Gathering business information related to network design
• Determining the scope of the design process
• Creating a preliminary schedule
• Gathering information about the applications you are using

Page 1-8 shows the three procedures of the Design Phase:

• Designing an eDirectory Tree - this is a required procedure. It includes setting a standard for eDirectory object names and values, and designing all layers of the Tree.
• Planning the User Environment - this is a required procedure. It helps you set login script standards, eDirectory security, and guidelines for the use of alias, directory map, and profile objects.
• Determining a Partition and Replica Strategy - If using NDS 7, this is a conditional procedure. It only needs to be done if the design is more complex than should be handled by the default strategy. Doing this helps provide scalability, fault tolerance, and accessibility of eDirectory across the internetwork.
  In this class, we are using eDirectory 8.5, so the procedure is no longer optional.

Page 1-10 discusses the Implementation Phase. It contains two procedures:

• Planning a Time Synchronization Strategy - If using NDS 7, this is a conditional procedure. It only needs to be done if your Tree has a WAN link or over 30 servers. It may be done at any time in the Design Phase.
  In this class, we are using eDirectory 8.5, so the procedure is no longer optional.

• The other procedure for this this phase is called by several names in this chapter. You may want to be able to recognize both Conducting an eDirectory Implementation and Implementing an eDirectory Design. Both phrases mean applying the design from the previous phases to a real Tree.

The last phase is discussed briefly on page 1-11: Analysis of Current eDirectory Design. The text explains that this phase involves the study of the actual Tree and how well it works for its organization. This phase is not discussed in detail in this course, since we have already covered these concepts in NetWare Administration and Advanced Administration.

Explain eDirectory design implications for a scenario of two merging companies

Page 1-12 introduces the case study for this course. The material from each chapter is meant to be applied to an ongoing case. The student is meant to create a solution for this case as the course continues. It is necessary to study the case material provided to complete the exercises for each chapter.