Home > Articles

Understanding the GroupWise Directory

  • Print
  • + Share This
This chapter is from the book

Chapter 3: Understanding the GroupWise Directory

This chapter explores how the various components of the GroupWise directory fit together. It examines some principles of administration and the flow of administrative messages through the GroupWise system, and it lays the groundwork for a very detailed discussion on troubleshooting and fixing the GroupWise directory in Chapter 22, "Fixing the GroupWise Directory." The GroupWise directory refers to the databases used to manage GroupWise objects.

GroupWise Directory Components

As mentioned in earlier chapters, the GroupWise directory uses both eDirectory and the GroupWise domain and post office databases. eDirectory and the GroupWise domain database (WPDOMAIN.DB) together provide the administration-level directory databases. The portion of the GroupWise directory that is replicated for GroupWise clients to use is the post office database (WPHOST.DB).

GroupWise domain, post office, and message store databases use an underlying architecture called FLAIM, which allows for billions of extensible records. Until 1999, eDirectory used a different architecture that was also extensible, but did not work as well for large numbers of records. In 1999, Novell released eDirectory Version 8, which also uses FLAIM as its underlying architecture. Despite the fact that the lowest-level structures are now similar, the two systems are still separate.

Figure 3.1 shows some important architectural concepts that need to be explored:

  • When administering GroupWise objects, most of the information goes into the GroupWise FLAIM databases.

  • Information in eDirectory is moderately important to GroupWise administration.

  • Every GroupWise domain database is essentially identical to every other record in other GroupWise domain databases.

  • GroupWise post office databases only accept information that has first flowed through their owning domain.

  • Not all information written to a domain database is written to a GroupWise post office database.

  • GroupWise post office databases are not modified by GroupWise administration.

Figure 3.1Figure 3.1 The GroupWise directory databases.

How eDirectory Is Used

It is important to understand that GroupWise evolved from WordPerfect Office. Before a heavy-duty, industry-recognized directory such as eDirectory came along, many applications had to have their own directory. With the release of GroupWise 5x, Novell began the process of merging the GroupWise directory with eDirectory. GroupWise administration requires eDirectory, but the primary domain database is still the ultimate authority in a GroupWise system.

Channeling GroupWise administration through eDirectory gives GroupWise administration two major improvements over versions that did not support eDirectory/Novell Directory Services (NDS) (and over many other applications that do not leverage eDirectory):

  • Authentication security: In older versions of GroupWise, if users could get into GroupWise administration, they could exert control over any object. Now, access to individual GroupWise objects and their properties can be controlled through eDirectory.

  • Single point of administration: Most GroupWise customers have already implemented an eDirectory directory tree. Having GroupWise mailboxes associated with their eDirectory user objects makes administration much easier. A phone number change or a name change has to be done only once.

Grafting GroupWise Objects with eDirectory

The process of controlling GroupWise objects through eDirectory is referred to as grafting. There are menu options in GroupWise administration that enable administrators to graft a domain, post office, or user into the eDirectory tree. The term graft might build a mental image in which a branch is taken from one tree and put on another tree.

Grafting GroupWise objects creates new objects in eDirectory, but those objects are fully contained in the WPDOMAIN.DB file. Most GroupWise objects in an eDirectory tree should be regarded as aliases, or pointers, to the actual object in the GroupWise FLAIM databases. Grafting objects into eDirectory allows objects to then be controlled through eDirectory.

The GroupWise directory is largely contained in GroupWise FLAIM databases. GroupWise FLAIM databases have their own repair and analysis tools, which are discussed in Chapters 17, "Maintaining the GroupWise System," and 22, "Fixing the GroupWise Directory." Rarely is a GroupWise directory problem fixed by running the eDirectory repair tool—DSREPAIR.

  • + Share This
  • 🔖 Save To Your Account