The GroupWise Domain Database

A GroupWise domain directory contains a critical file, WPDOMAIN.DB, as shown in Figure 3.2. This is the domain database.

Figure 3.2. A GroupWise WPDOMAIN.DB file in a domain directory

Creating the First WPDOMAIN.DB File (the Primary Domain)

When a GroupWise system is created, a WPDOMAIN.DB file for the primary domain is created based on the following:

• Information that the administrator inputs

• Information from eDirectory

• Information from the domain structure, or dictionary file, called GWDOM.DC

The GWDOM.DC file is located at the root of any domain's directory. The GWDOM.DC file is an ASCII text file that defines the structure for all GroupWise 7 domain databases. The GWDOM.DC file should never be edited or modified.

Creating Secondary Domains

When a GroupWise secondary domain is originally created, it is created from information in the WPDOMAIN.DB file from the primary domain and the generic GWDOM.DC file. The information in a GroupWise secondary domain is an exact duplicate of the information in the primary domain. The only thing that makes the primary domain "primary" is that the Domain Type field, shown in Figure 3.3, reads as Primary.

Figure 3.3. The domain type for the primary domain

A secondary domain's Domain Type field, shown in Figure 3.4, reads as Secondary.

Figure 3.4. The domain type for a secondary domain

How a WPDOMAIN.DB File Changes and Increases in Size

As new objects and users are added to a GroupWise system, those objects are replicated to every WPDOMAIN.DB file in a GroupWise system. Deletions and changes of objects are also replicated to every WPDOMAIN.DB file in a GroupWise system. The only two entities that write to a WPDOMAIN.DB file are the following:

• GroupWise administration snap-ins in ConsoleOne

• The admin thread of the GroupWise MTA

Suppose a GroupWise directory update message is sent from the CORP domain to the MFG domain. The administrator who makes the change is connected to the CORP domain, so GroupWise administration snap-ins write the changes to WPDOMAIN.DB for CORP. The CORP MTA sends the update to MFG. Now the MFG domain's MTA will be responsible for updating the MFG domain database (WPDOMAIN.DB) file.

The Role of Domain Databases and Information Replication

Ideally, each GroupWise domain database has a record for every object in the GroupWise system. When a GroupWise domain adds an object, it transmits a copy of that object to the primary domain, to be replicated to all other domains. Larger GroupWise systems are in a constant state of change. A change to a GroupWise object should take a short while to replicate to all other domains, but on a large system, "a short while" might mean 15 minutes or more.

This means that if for some reason one of your domain databases is damaged, you should recover it from tape backup or rebuild it, which is always done from the primary domain's database. Recovering a domain database from a backup tape that is more than a day old can result in serious synchronization problems with the other domains.

Understanding the Directory Role of the Domain Database

The administration role of the WPDOMAIN.DB is to contain GroupWise objects in a database. With the help of GroupWise administration snap-ins, GroupWise objects in the WPDOMAIN.DB file can be created and modified. Whenever you administer your GroupWise system, GroupWise administration is connected to any one of the WPDOMAIN.DB files in your system. One WPDOMAIN.DB file exists for each domain. GroupWise administration enables you to connect to any one of your domains.

The GroupWise directory is a fully replicated directory. This means the following:

• Every object that primary DOMAINA has ownership of is replicated to the secondary DOMAINB and DOMAINC.

• Every object that DOMAINB has ownership of is replicated to the primary domain DOMAINA and consequently to the secondary DOMAINC.

• Every object that DOMAINC has ownership of is replicated to the primary DOMAINA and consequently to the secondary DOMAINB.

If GroupWise administration is connected to DOMAINA, you can still modify almost all the objects that DOMAINB owns (as long as you have the eDirectory rights to that object). This process is explained in the following section, "Understanding Object Ownership." For those familiar with eDirectory, this object modification model might seem different. The GroupWise replication model is different from eDirectory in these two ways:

• eDirectory uses a partitioned architecture. Although a server might contain eDirectory databases, the objects in those databases do not necessarily represent all the objects in an eDirectory tree.

• eDirectory requires that only servers with replicas of a particular partition be allowed to accept changes to the objects.

The primary reason the GroupWise replication model is different from eDirectory is that the GroupWise directory is not extensible, and will never grow to the size of an eDirectory tree.

Understanding Object Ownership

Every user must be associated with a post office. Every GroupWise post office must be associated with a GroupWise domain. Consider the following scenario:

DOMAINA owns a post office called POST1, and POST1 has Eva Cornish associated with it. In this scenario, the following information can be extrapolated:

• DOMAINA owns POST1.

• Eva Cornish is associated with POST1.

• DOMAINA must own the object Eva Cornish.

Ownership is an important role because it plays a key part in ensuring that an object or a record is properly synchronized across all domain databases (WPDOMAIN.DB files).

There are some objects that are considered system records. System records are actually owned by the primary domain. Some examples of system records are Software Distribution Directories, Internet Domain definitions, and Restore Areas.

How GroupWise Objects Stay Synchronized

Only the GroupWise domain that owns a particular object or record can officially approve a change to an object. Another domain might propose a change to an object or a record, but that proposal must be approved by the object's owning domain. Here's an example in which the whole process of GroupWise directory changes is drawn out.

Consider the following scenario: Secondary DOMAINB owns Eva Cornish. The GroupWise administration snap-ins for ConsoleOne are connected to secondary DOMAINC (a domain that does not own the object being modified) and change the phone number for Eva Cornish:

• DOMAINC: Secondary domain

  • Eva Cornish's phone number is changed.

  • The record for Eva Cornish in DOMAINC's WPDOMAIN.DB file is changed from safe to modify.

  • The proposed change is sent to DOMAINB by DOMAINC's MTA.

  • The administrator can view the proposed change while connected to DOMAINC by selecting Tools, GroupWise System Operations, Pending Operations.

• DOMAINB: Secondary domain

  • DOMAINB's MTA receives the change information from DOMAINC and accepts the change. It changes the user object's phone number in its WPDOMAIN.DB.

  • DOMAINB increments the record version of this object from version 1 (version 1 was initial creation) to version 2. The fact that the record version value increments to 2 is not propagated to other domains.

  • DOMAINB's MTA creates a message destined to the primary domain telling the primary domain about the change to the object Eva Cornish.

  • DOMAINB's MTA creates a message destined for the post offices that it owns, indicating the change to the object Eva Cornish.

• DOMAINA: Primary domain

  • DOMAINA's MTA receives from DOMAINB the change to object Eva Cornish to its WPDOMAIN.DB file.

  • DOMAINA's MTA creates a message and sends this message to all other domains (except DOMAINB), telling all other domains to rewrite this entire user object record with the information that the primary domain is sending about this object record.

  • DOMAINA's MTA creates a message and sends this message to each of its own post offices indicating the change to Eva Cornish.

• DOMAINC: Secondary domain

  • DOMAINC's MTA receives from DOMAINA the change to object Eva Cornish to its WPDOMAIN.DB file.

  • DOMAINC changes the record on object Eva Cornish from modify to safe.

  • DOMAINC sends a message to each of its own post offices indicating the change to the object Eva Cornish.

• All other secondary domains

  • DOMAINX's MTA receives from DOMAINA the change to object Eva Cornish to its WPDOMAIN.DB file.

  • DOMAINX's MTA sends a message to each of its own post offices indicating the change to object Eva Cornish.

From the preceding synchronization detail, the following conclusions can be drawn about how objects are synchronized to the GroupWise directory:

• If an administrator has eDirectory rights to do so, he or she can be connected to any domain in the system and modify objects associated with another domain.

• The only domain that can approve an object change is the domain that owns the object.

• The only domain that can propagate object changes to an entire GroupWise system is the GroupWise primary domain.

• Each domain is responsible for propagating directory changes to the post offices that it owns.

Knowing the Agent Information Role of the Domain Database

When a GroupWise MTA loads, it must point to the root of the domain directory, which contains the WPDOMAIN.DB file. The WPDOMAIN.DB file provides three basic types of information to the MTA:

• Configuration information: When to connect, how many threads to load, and so on.

• Link information: How to establish a connection with the other domains on the system.

• Routing information: Discovering the correct route to use to send messages to their destinations.

The MTA specifically reads the MTA object record associated with the domain that the MTA points to. Under Tools, GroupWise Diagnostics, Record Enumerations, this record is found in the Message Transfer Agents by Domain section.

The other processes that access the WPDOMAIN.DB file directly are the GroupWise Internet Agent (GWIA), the WebAccess Agent, and the various GroupWise gateways. They all need the same basic kind of information:

• Configuration information: When to connect, how many threads to load, and so on.

• Addressing information: Looking up users to deliver inbound mail to them.