Novell GroupWise 7 Administrator Solutions Guide
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:
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:
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:
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:
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:
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:
From the preceding synchronization detail, the following conclusions can be drawn about how objects are synchronized to the GroupWise directory:
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:
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:
|