eDirectory is the world's leading directory service. It provides a
unifying, cross-platform infrastructure for managing, securing, accessing, and
developing all major components of your network. eDirectory scales to the
largest network environments, including the Internet. Because it is based on the
X.500 standard, eDirectory supports LDAP, HTTP, and the Java programming
environment.

eDirectory can store and manage millions of objects in a seamless ballet of
communications. It also provides the foundation network service for all NetWare
servers and network resources. In fact, after network communications, it is the
most fundamental network service offered by NetWare 6.

With all of this in mind, I'm sure you would agree that eDirectory
management is one of your key responsibilities as a Novell CNE (Certified Novell
Engineer). In this chapter, we will explore three important lessons regarding
eDirectory management:

Understanding eDirectory 8.6First, we'll begin with a
brief lesson in the architecture of eDirectory 8.6 and compare it to its
predecessor, Novell Directory Services (NDS).

Maintaining eDirectory 8.6In the final lesson of this
chapter, we will explore a comprehensive eDirectory maintenance plan to help
ensure the health of your directory. First, you'll learn how to use the
Index Manager capabilities of ConsoleOne to maintain eDirectory indexes and to
increase the performance of your network. Then, you'll learn how to reduce
synchronization traffic by configuring filtered replicas of specific eDirectory
8.6 partitions. Finally, you'll learn how to optimize eDirectory by
configuring eDirectory cache.

As you can see, there's a lot to learn in this chapter and when
it's all done, you'll be an accomplished eDirectory engineer. So,
let's get started at the beginningUnderstanding eDirectory 8.6.

Earlier versions of eDirectory were called Novell Directory Services (NDS).
At first glance, eDirectory appears to have the same underlying architecture as
NDS. That is, a distributed, object-oriented database organized as a
hierarchical tree. Upon closer inspection, however, you'll find that
eDirectory 8.6 is built on a much more sophisticated database structure than
NDS.

Let's take a closer look at the underlying architectural differences
between NDS and eDirectory, starting with NDS.

NDS Architecture

NDS was first introduced in NetWare 4. Prior to NetWare 4, NetWare operating
systems relied on a server-centric modelin which each NetWare server had
its own flat-file database for tracking network resources (called the
bindery). The bindery consisted of three files: one that held object, one
that held property, and one that held value information.

NDS offered a gigantic leap forward by evolving the server-centric model into
a network-centric model. In this architecture (shown in Figure
3.1), the NetWare 4 operating system relies on four data files and multiple
streams files located in a hidden directory on the server's SYS: volume.
This database is referred to as the RECMAN database.

NDS streams files are named with hexadecimal characters (0-9, A-F) and
hold information such as print job configurations and login scripts. Earlier
versions of NDS used Novell's Transactional Tracking System (TTS) to ensure
that database transactions were either completed or backed out in the event of a
system failure.

TIP

The NetWare 5 version of NDS uses the same architecture as described above;
however, the names of the files are different. In NetWare 5, ENTRY.NDS
is called 0.DSD, VALUE.NDS is called 1.DSD, BLOCK.NDS
is called 2.DSD, and PARTITIO.NDS is called 3.DSD.

eDirectory 8.6 Architecture

eDirectory 8.6 improves on NDS' fixed-length record data store model by
introducing a highly scalable indexed database called FLAIM (FLexible
and Adaptable Information Manager). The FLAIM database uses three different
types of files instead of four, but still relies on streams files for print
job configurations and login scripts. Check out the eDirectory 8.6 architecture
in Figure 3.2.

Following is a description of each of the three different types of files that
make up eDirectory's FLAIM database:

NDS.DBThe control file is the centerpiece of the
eDirectory architecture. This file contains the rollback log and is used to
abort incomplete transactions.

NDS.01The primary database file contains all
records and indexes found on a given server. When this data file reaches 2GB in
size, NDS.02 is created for the remaining data. New files are then
created as necessary to keep database files from growing beyond 2GB. This allows
the database files to remain scalable while retaining their quick-search
capabilities.

NDS*.LOGThe transaction log file acts as a roll-forward
log to reapply completed transactions that might not have been fully written to
disk because of a system interruption.

eDirectory streams files perform the same function as they do in NDS and have
an .NDS extension. However, unlike NDS, eDirectory does not use TTS;
instead, it uses log files to back out and roll forward transactions in the
event of a system failure. Refer to Table 3.1 for a summary of the differences
between NDS and eDirectory architecture.

TIP

The primary eDirectory database file, NDS.01, includes a number
of indexes to enhance performance. First, it includes attribute substring
indexes for the "CN" and "uniqueID" fields. Second, it
includes attribute indexes for the "Object Class" and "dc"
fields. Finally, it includes attribute indexes for positioning that include
strings beginning with CN, uniqueID, Given Name, and Surname.

Table 3.1 Comparing NDS and eDirectory Architecture

Component

NDS

eDirectory

Database Name

RECMAN

FLAIM

Database Function

Fixed-Length Record Data Store

Highly Scalable Indexed Database

NetWare Version

4.x and 5.x

6.0

Number of Files

4

3

Data Records File

ENTRY.NDS

NDS.01

Roll-Back Mechanism

TTS

Log Files

Streams

Yes

Yes

The eDirectory architecture described here provides an
exceptional foundation for all of eDirectory 8.6's new features and
benefits. Following is a brief list of some of eDirectory's greatest new
advancements:

eDirectory 8.6 can be implemented on any of these operating system
platforms: NetWare, Windows NT, Windows 2000, Linux, Solaris, and Tru64 UNIX.
Client libraries and LDAP tools are available for Linux, Solaris, and Tru64
UNIX. LDAP support provides an open structure for integration with applications
that are written to the LDAP standard.

The eDirectory Import/Export Wizard enables you to import or export LDIF
files and to perform a server-to-server data migration.

eDirectory includes a merge utility that enables you to merge one
directory tree into another or to graft one tree onto another.

iMonitor provides monitoring and diagnostic capabilities for all servers
in your eDirectory tree from a web browser.

This completes our architectural lesson of eDirectory 8.6. We hope that you
have gained an appreciation for the sophisticated directory services platform
that eDirectory 8.6 provides for your NetWare 6 network. Now that you understand
how it's built, you're ready to learn how to integrate it into your
existing network.